From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
Date: Tue, 15 Sep 2015 14:01:30 +0200 [thread overview]
Message-ID: <87k2rrvqlh.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20150915114159.758baca9@free-electrons.com> (Thomas Petazzoni's message of "Tue, 15 Sep 2015 11:41:59 +0200")
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> 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.
Yes, and these new packages may or may not build/work with the old
kernel (and presumably toolchain).
>> 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.
Yes, but adding one more option that is only a slight variant of one of
them doesn't help.
When would we remove this option again? When 2.6.32 comes 10 years old?
15?
>> 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 ? :-)
Argh, the 'non' shouldn't have been there ;)
>> 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.
And we expect that to be a significant amount of people?
> 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).
Packages indeed very rarely add complexity elsewhere. And yes, reviewing
the finer inittab details is indeed good.
>> 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?
From a quick look (depending on how old the kernel is) I think it is
basically just device_get_nodename():
commit 6fcf53acccf85b4b0d0260e66c692a341760f464
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu Apr 30 15:23:42 2009 +0200
Driver Core: add nodename callbacks
This adds the nodename callback for struct class, struct device_type and
struct device, to allow drivers to send userspace hints on the device
name and subdirectory that should be used for it.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>> 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.
So in other words, <3.x isn't really supported.
>> 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
Or alternatively, extend the S10mdev logic to detect that it need to
create a tmpfs on /dev (by looking for devtmpfs in /proc/filesystems or
detecting that /dev is RO) and have all the fixup there. That way it
atleast doesn't add any more complications to the rest of Buildroot /
users.
>> 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.
Or alternatively, one of the other options suggested above.
--
Venlig hilsen,
Peter Korsgaard
next prev parent reply other threads:[~2015-09-15 12:01 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
2015-09-15 12:01 ` Peter Korsgaard [this message]
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=87k2rrvqlh.fsf@dell.be.48ers.dk \
--to=peter@korsgaard.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.