From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [git commit] perf: add kernel version checks
Date: Tue, 08 Jan 2013 09:28:15 +0100 [thread overview]
Message-ID: <50EBD89F.6050409@mind.be> (raw)
In-Reply-To: <20130108091534.38d07446@skate>
On 08/01/13 09:15, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Tue, 08 Jan 2013 07:41:44 +0100, Arnout Vandecappelle wrote:
>
>> There are a number of packages that would benefit from kernel version
>> checks. For instance, the native driver implementations of igh-ethercat
>> are specific for a certain kernel version. Would it be a good idea to
>> make the kernel version user-configurable, and add a check for its
>> correctness similar to the external toolchains?
>
> Huh? The kernel version is already user configurable, thanks to the
> BR2_LINUX_KERNEL_3_7, BR2_LINUX_KERNEL_SAME_AS_HEADERS,
> BR2_LINUX_KERNEL_CUSTOM_VERSION, BR2_LINUX_KERNEL_CUSTOM_TARBALL,
> BR2_LINUX_KERNEL_CUSTOM_GIT configuration options.
>
> The thing is that when the BR2_LINUX_KERNEL_CUSTOM_TARBALL or
> BR2_LINUX_KERNEL_CUSTOM_GIT options are used, you don't know (at the
> Kconfig level), the kernel version that will be used.
>
> And I don't think we should ask the user to tell us, through a separate
> option, what kernel version his/her Git tree actually contains.
>
> Or maybe I'm missing what you're proposing here?
I propose what you just said we shouldn't do: ask the user to tell us,
through a separate option, what kernel version his/her git tree actually
contains. Similar to the configuration of a preinstalled external toolchain.
> Regarding the kernel and the autobuilders, my plan was to modify the
> autobuilders script to randomly enable the kernel build. The script of
> course knows, per-architecture, of a known-working kernel defconfig
> file that it would use in the Buildroot configuration.
It will be hard to find a kernel version that is supported by all of
linux-fusion, igh-ethercat, owl-linux, lttng-modules and perf (and then
I'm leaving out Xenomai and RTAI). For my all-package build, I just
disabled those because it was too difficult to find a good one.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
next prev parent reply other threads:[~2013-01-08 8:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-07 20:40 [Buildroot] [git commit] perf: add kernel version checks Peter Korsgaard
2013-01-08 6:41 ` Arnout Vandecappelle
2013-01-08 8:15 ` Thomas Petazzoni
2013-01-08 8:28 ` Arnout Vandecappelle [this message]
2013-01-08 8:42 ` Thomas Petazzoni
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=50EBD89F.6050409@mind.be \
--to=arnout@mind.be \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.