[Buildroot] [PATCH] linux: enable UEVENT_HELPER when mdev is used

Peter Korsgaard peter at korsgaard.com
Mon Jun 3 14:56:47 UTC 2019


>>>>> "Arnout" == Arnout Vandecappelle <arnout at mind.be> writes:

Hi,

 >> > start-stop-daemon -S -b -x /sbin/uevent -- mdev
 >> 
 >> Ahh, so busybox now has a clone of s6-uevent-listener / mdevd-netlink? I
 >> wasn't aware of that.

 >  It has been added in 2015 :-)

As I said, I don't use mdev ;)

 >> > 1. Bloat the kernel with legacy uevent helper support (this patch).
 >> 
 >> This is not really bloat, as it just makes the existing implicit
 >> dependency explicit.

 >  It is "bloat" because there is a way to avoid it, but the user can't disable it
 > (even if the user modifies the init script to use uevent so it becomes unneeded,
 > Buildroot forces the kernel option on).

Correct.


 >> > 2. Bloat the kernel with networking even if it is not used for anything else,
 >> > and bloat busybox with uevent (3.1 kb), and always use uevent.
 >> 
 >> Networking support adds significant bloat, the other options afaik not.

 >  Note that it's just CONFIG_NET, not CONFIG_INET. Without CONFIG_NET, you don't
 > have e.g. the socket() syscall. 90% of the packages will not work (at runtime).
 > So we're kind of in the same domain as with a custom uClibc config that disables
 > stuff that most packages depend on.

How will the uevent daemon work without socket()?

 >> > 3. Use uevent in the init script but don't enforce anything (with potential
 >> > silent failures), and explain stuff in the mdev help text.
 >> 
 >> > 4. Try out all possibilities in the init script - which still fails silently in
 >> > case neither CONFIG_UEVENT_HELPER nor CONFIG_NET is enabled in the kernel.
 >> 
 >> >  In my opinion, we definitely should *not* go for option 1. I don't want to be
 >> > the one that forces the kernel to maintain legacy stuff. I would definitely use
 >> > uevent.
 >> 
 >> What advantage does uevent have over the legacy uevent helper? Just
 >> serialization or anything else?

 >  It's also more efficient IIUC, but I don't know much of the details.
 > Admittedly, that efficiency probably goes away with uevent, because it stems
 > from avoiding a fork, but uevent does exactly that.

Indeed. Notice that Denys has just merged the daemon mode (-d) support
for mdev, so from a performance PoV, that is probably what we should
support rather than uevent + mdev:

http://lists.busybox.net/pipermail/busybox/2019-June/087305.html


 >> I don't use mdev myself, so I don't really care a lot about what option
 >> we go for longer term, but given how close 2019.05 is, the only valid
 >> options for the release are this patch or nothing.

 >  As Andy indicated, this bug has existed for several years. I really don't see
 > the need to fix it for 2019.05.

.. so I didn't.


 >> Ahh yes, a patch adding an 'echo >/dev/mdev.seq' to S10mdev would be
 >> nice.

 >  But not needed if we use uevent :-)

Not if we unconditionally do it, no.

-- 
Bye, Peter Korsgaard


More information about the buildroot mailing list