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 10:09:39 +0200 [thread overview]
Message-ID: <87zj0oumrg.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20150915093030.622d2366@free-electrons.com> (Thomas Petazzoni's message of "Tue, 15 Sep 2015 09:30:30 +0200")
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> Yes, but I still question the need for all of this work in the first
>> place.
> 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.
> 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.
I agree that it isn't a _LOT_ of complexity, but it isn't non trivial
either.
>> 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?
> Luca is using a vendor-specific kernel in which the entire SoC support
> is not in mainline. So moving to a newer kernel is simply not an option
> (or an option with a several man-years effort, which for many companies
> is the same as "not an option").
I get that.
> 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.
>> 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.
> So far, Luca has provided some patches that are perfectly documented,
> along with test cases and test scripts to validate the booting with
> all possible /dev management situations. To me, the perfectness of
> Luca's contribution is a good enough argument to merge this feature
> :-)
I agree, the patches themselves are very nice work!
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.
--
Venlig hilsen,
Peter Korsgaard
next prev parent reply other threads:[~2015-09-15 8:09 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 [this message]
2015-09-15 9:41 ` Thomas Petazzoni
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=87zj0oumrg.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.