[Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
Luca Ceresoli
luca at lucaceresoli.net
Tue Sep 15 22:31:34 UTC 2015
Dear Peter, Thomas,
Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni at 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
More information about the buildroot
mailing list