From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
Date: Wed, 16 Sep 2015 00:31:34 +0200 [thread overview]
Message-ID: <55F89C46.3010904@lucaceresoli.net> (raw)
In-Reply-To: <87zj0oumrg.fsf@dell.be.48ers.dk>
Dear Peter, Thomas,
Peter Korsgaard wrote:
>>>>>> "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.
I agree with you on the principle, but in the practice I have devices
running very fine on 2.6.30 and some user space applications using
C++11. Yes, I used a fairly recent toolchain (gcc 4.8 IIRC), which is
of course a bad idea, I know... But in the practice it works. I had to
spend a little time to check some packages that try to use kernel
features not available in the running kernel. IIRC I only had issues
with dhcpcd which tends to use recently-introduced syscalls. Other
packaged run without problems.
>
>
> > 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.
FWIW, it's even less complex in the v2 patchset that's half-brewed here.
> > 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.
I think I had a look a couple of years ago when I did the first project
on the same SoC. I think I had a look and found it non trival, but the
product to create had no hotplugging capabilities and no firmware
loading needs, so I just went for a static /dev.
Now I have a real goal, so I might try harder to look into backporting
devtmpfs.
> > 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!
Thanks both! :)
--
Luca
next prev parent reply other threads:[~2015-09-15 22:31 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
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 [this message]
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=55F89C46.3010904@lucaceresoli.net \
--to=luca@lucaceresoli.net \
--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.