From: Michael S. Zick <minimod@morethan.org>
To: buildroot@busybox.net
Subject: [Buildroot] Real time Linux implementation
Date: Sat, 3 Dec 2011 04:53:41 -0600 [thread overview]
Message-ID: <201112030453.45164.minimod@morethan.org> (raw)
In-Reply-To: <20111203000854.6dcc2764@skate>
On Fri December 2 2011, Thomas Petazzoni wrote:
> Le Fri, 02 Dec 2011 19:33:47 +0100,
> Stephan Hoffmann <sho@relinux.de> a ?crit :
>
> > what do you think about adding the PREEMPT_RT patch as a config option
> > to buildroot?
>
> That would definitely be nice. The only problem is that PREEMPT_RT is
> far from being available for every upstream kernel version, so it's a
> bit hard to integrate from that perspective, but this isn't much
> different from Xenomai and RTAI having similar kernel version
> constraints. So, yes, having some PREEMPT_RT integration would be nice,
> at least to show that it is possible.
>
And the pending EtherCAT patch which has both kernel version constraints
and supports only a few specific Ethernet adapters.
Having the new "kernel extensions" build support is a nice feature.
And BR does target building embedded systems where "strange and unusual"
kernel extensions are sometimes a way-of-life, but...
Will the project need a general policy of just how "strange and unusual"
will be considered for inclusion in the build system?
My reason for posing this question early in the life-time of the
"kernel extensions" feature is the on-going maintenace chore of
these specializations.
Often, it will take the actual downloading and examination of each
source package by someone who is also familiar with that BR patch
to do a "version bump" of that kernel extension package.
Maybe a policy of whoever proposes the extension also accept the
responsibility of maintaining its "version bumps"?
And then if a kernel extension gets too old or becomes unusable,
let the normal deprecated/remove maintenace routine get rid of it.
I can't see that expecting the usual maintainers of the BR system
to take on these extra chores of maintaining the "specials" is
reasonable.
Perhaps this question is too early, but worth bookmarking until
we see just how many one-user, one-time, things get proposed.
Mike
> Regards,
>
> Thomas
next prev parent reply other threads:[~2011-12-03 10:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-01 19:27 [Buildroot] Real time Linux implementation Morten Jensen
2011-12-01 21:18 ` Thomas Petazzoni
2011-12-02 18:33 ` Stephan Hoffmann
2011-12-02 23:08 ` Thomas Petazzoni
2011-12-03 10:53 ` Michael S. Zick [this message]
2011-12-03 11:08 ` Thomas Petazzoni
2011-12-03 11:24 ` Michael S. Zick
2011-12-07 8:34 ` Julien Boibessot
2011-12-09 18:55 ` 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=201112030453.45164.minimod@morethan.org \
--to=minimod@morethan.org \
--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