From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v3] usbip: new package
Date: Wed, 26 Dec 2012 18:32:20 +0100 [thread overview]
Message-ID: <20121226183220.2cf4b9c7@skate> (raw)
In-Reply-To: <defa5c66-81f8-43bf-b529-5d890db965d4@zimbra2.corp.accelance.fr>
Dear Jeremy Rosen,
On Wed, 26 Dec 2012 17:49:57 +0100 (CET), Jeremy Rosen wrote:
> I would be interested too, more and more tools are distributed with
> the kernel that we might want to build... I'm thinking of the perf
> tools in particular
>
> is there an example somewhere on how to handle these ?
Unfortunately, there isn't a really good and nice way of handling these
in Buildroot for now.
I see two options:
* Add sub-options to the "Linux kernel" package, to allow the
installation of perf, usbip or other userspace packages whose source
code is bundled with the kernel source code. This is the easiest
solution, since the kernel version, sources and al. is already
defined. But it also has major drawbacks: 1/ it makes those tools
available only if you build your kernel with Buildroot and 2/ it
puts the configuration options to install those tools inside the
"Linux kernel" menu, which is not very intuitive.
* Add separate packages for each of those tools in package/, with
those packages depending on the "linux" package. The extract step of
those packages could copy the source code of these tools from the
Linux kernel source tree into their build directory, or simply build
then directly from within the Linux kernel source tree. It solves
drawback (2) described above, but not drawback (1).
* Add separate packages for each of those tools in package/, and make
them independent from the Linux package. They would for example
download the latest stable version of the Linux kernel source code,
and use that as a source. The extract step could be customized to
only extract the part of the kernel sources that are actually
relevant for this package. This would solve both drawbacks (1) and
(2), but adds different drawbacks: it's another place where we have
to bump the kernel version regularly, and people may want to
configure the version of the kernel sources used to build those
tools: the primary reason why those tools are bundled with the
kernel sources is because the userspace-to-kernel ABI specific to
those tools gets changed from time to time, and therefore there may
be compatibility issues in running those tools from kernel version X
under a system running kernel version Y.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2012-12-26 17:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-26 6:44 [Buildroot] [PATCH] usbip: new package Marcin Bis
2012-12-26 7:06 ` Baruch Siach
2012-12-26 8:27 ` [Buildroot] [PATCH v2] " Marcin Bis
2012-12-26 8:49 ` [Buildroot] [PATCH] " Thomas Petazzoni
2012-12-26 8:55 ` [Buildroot] [PATCH v3] " Marcin Bis
2012-12-26 16:35 ` Baruch Siach
2012-12-26 16:49 ` Jeremy Rosen
2012-12-26 17:32 ` Thomas Petazzoni [this message]
2013-08-13 21:20 ` Thomas Petazzoni
-- strict thread matches above, loose matches on Subject: below --
2016-12-12 22:17 [Buildroot] [PATCH] usbip: add a " Tal Shorer
2016-12-12 22:21 ` [Buildroot] [PATCH v3] usbip: " Tal Shorer
2016-12-13 17:53 ` Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121226183220.2cf4b9c7@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox