From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
Date: Tue, 15 Sep 2015 11:41:59 +0200 [thread overview]
Message-ID: <20150915114159.758baca9@free-electrons.com> (raw)
In-Reply-To: <87zj0oumrg.fsf@dell.be.48ers.dk>
Hello,
On Tue, 15 Sep 2015 10:09:39 +0200, Peter Korsgaard wrote:
> > On my side, I don't. Some people are still forced to use 2.6.x kernels
> > older than 2.6.32, and if Luca (who is a knowledgeable and
> > skilled developer) has such a need, I'm sure it means there is a silent
> > group of people stuck with prehistoric kernels that would benefit from
> > this.
>
> Sure, I get that. I just question the sensibility of combining a 6+ year
> old kernel with modern user space.
Well, it is quite understandable that Luca would like to use a recent
and modern Buildroot for his project. But since Buildroot is a bundle
of a build infrastructure *and* package recipes, you can't get a recent
and modern Buildroot without getting a recent and modern user-space.
> > In addition, the changes that Luca is proposing are very
> > self-contained, and often shared with the other /dev management
> > solutions. So I don't see a lot of additional complexity in what Luca
> > is proposing.
>
> I do, it is yet another slightly different variant of the /dev
> handling to confuse new users and complicate the build logic.
Well, the /dev handling already has a number of different options, and
the user must anyway understand a little bit how a Linux system is
working to make a sensible choice between the different options. The
default is sane, and will remain the same, so that clueless users
continue to get the same experience/result.
I don't think a new variant of /dev management is that more complicated
than the "OpenMP support", "stack smashing protection support" or "LTO
support" options we have in the Toolchain menu.
> I agree that it isn't a _LOT_ of complexity, but it isn't non trivial
> either.
If it "isn't non trivial", then it is trivial, right ? :-)
> >> Is there any reason for NOT using devtmpfs if it is available?
>
> > Well the point is precisely that it isn't.
>
> What I meant is actually if this option is only useful for the (few?)
> Buildroot users with <2.6.32 kernels that want mdev support, or also for
> others?
Yes, it is probably only for people using kernels older than 2.6.32 who
need mdev for automatic module loading, or firmware loading.
There might be more users of such a thing that there are users of some
of our weird packages. Admitted, a package is just a package and
doesn't add any complexity to the core. But the additional complexity
brought by Luca's work is relatively small. And his work has in fact
uncovered a few issues in our existing code (the fact that we redirect
the output of all inittab commands to /dev/null, and that some of them
are in fact failing without us noticing).
> > I'm not sure how complicated it is to backport devtmpfs. However I
> > would suspect that it isn't that easy.
>
> Take a look at 2b2af54a5bb6f7e80ccf78f20084b93c398c3a8b in the
> kernel. To me it looks quite self contained, so backporting it to
> something close to 2.6.32 doesn't look too bad.
Indeed. I wonder how many dependencies on other patches it has, though.
Luca, can you give it a try and see if it would work for you?
> >> We certainly don't test such old kernel headers in the autobuilders.
>
> > Indeed, we don't. But we could ask Luca, as part of this patch series,
> > to help us add such a toolchain in our autobuilders.
>
> I'm not sure I'm really interested in seeing a bunch of patches adding
> 'depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_2_6_<old>' / comments to
> packages.
Right, this I understand. We could keep the current state of things:
dependencies are only for >= 3.x kernels. So if something builds with
2.6.38 but not 2.6.32, then we don't care, and we make it depend on >=
3.x. Though I agree some people using 2.6.35 might complain, as they
can technically build that thing.
> But I still need to be convinced that adding this other mdev variant is
> the best tradeoff between:
>
> - Adding the patches
>
> - Ask people to backport devtmpfs to their kernel
>
> - Ask people to handle it in a post-build script
>
> - Ask people to add a initramfs mounting a tmpfs on /dev + mknod before
> executing init
>
> - Asking people to stick with user space of the same "maturity" ;) as
> their kernel
>
> If there's other people interested in this feature, then it would be
> nice to hear from you.
I agree getting more feedback from other potential users would be good.
However, I fear that many of the people who are stuck with old crappy
kernels are also in companies that are not necessarily very open, and
we may simply never hear from them.
So, as suggested above, Luca, can you try to backport devtmpfs? If that
solves the problem, then it's probably a good enough solution.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-09-15 9:41 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 21:28 [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 1/6] Move mounting /sys from fstab to inittab Luca Ceresoli
2015-09-09 9:12 ` Arnout Vandecappelle
2015-09-08 21:28 ` [Buildroot] [RFC 2/6] system: clarify /dev management using devtmpfs + {mdev, eudev} Luca Ceresoli
2015-09-09 9:40 ` Arnout Vandecappelle
2015-09-09 10:53 ` Luca Ceresoli
2015-09-09 10:54 ` Arnout Vandecappelle
2015-09-08 21:28 ` [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs) Luca Ceresoli
2015-09-09 9:21 ` Arnout Vandecappelle
2015-09-09 12:29 ` Luca Ceresoli
2015-09-09 12:32 ` Arnout Vandecappelle
2015-09-09 13:54 ` Thomas Petazzoni
2015-09-14 13:47 ` Luca Ceresoli
2015-09-14 22:23 ` Arnout Vandecappelle
2015-09-15 22:35 ` Luca Ceresoli
2015-09-14 20:53 ` Peter Korsgaard
2015-09-14 21:34 ` Thomas Petazzoni
2015-09-14 21:38 ` Peter Korsgaard
2015-09-15 7:30 ` Thomas Petazzoni
2015-09-15 8:09 ` Peter Korsgaard
2015-09-15 9:41 ` Thomas Petazzoni [this message]
2015-09-15 12:01 ` Peter Korsgaard
2015-09-15 12:27 ` Arnout Vandecappelle
2015-09-15 12:32 ` Peter Korsgaard
2015-09-18 16:37 ` Luca Ceresoli
2015-09-15 13:03 ` Thomas Petazzoni
2015-09-15 13:14 ` Peter Korsgaard
2015-09-15 22:34 ` Luca Ceresoli
2015-10-01 9:36 ` Luca Ceresoli
2015-10-01 10:03 ` Peter Korsgaard
2015-09-15 22:31 ` Luca Ceresoli
2015-09-16 7:32 ` Peter Korsgaard
2015-09-18 15:47 ` Luca Ceresoli
2015-09-09 9:34 ` Arnout Vandecappelle
2015-09-09 11:23 ` Thomas Petazzoni
2015-09-09 11:29 ` Thomas Petazzoni
2015-09-09 20:33 ` Arnout Vandecappelle
2015-09-14 16:07 ` Luca Ceresoli
2015-09-14 16:05 ` Luca Ceresoli
2015-09-14 19:34 ` Thomas Petazzoni
2015-09-14 20:19 ` Arnout Vandecappelle
2015-09-15 22:07 ` Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 4/6] system: strip the initial /dev for mdev-only /dev management Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 5/6] docs/manual: document "Dynamic using mdev only" " Luca Ceresoli
2015-09-09 10:39 ` Arnout Vandecappelle
2015-09-08 21:28 ` [Buildroot] [RFC 6/6] **** DO NOT COMMIT THIS **** ugly stuff to test mdev-only " Luca Ceresoli
2015-09-09 9:26 ` [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Arnout Vandecappelle
2015-09-09 11:30 ` Thomas Petazzoni
2015-09-14 21:03 ` Peter Korsgaard
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=20150915114159.758baca9@free-electrons.com \
--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 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.