[Buildroot] [PATCH] linux: enable UEVENT_HELPER when mdev is used
Titouan Christophe
titouan.christophe at railnova.eu
Mon Jun 3 16:44:50 UTC 2019
Hi all,
On 6/3/19 4:56 PM, Peter Korsgaard wrote:
>>>>>> "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
This is great news !
Even then, the S10mdev init script has to be modified to start mdev in
daemon mode. I could add this to
http://patchwork.ozlabs.org/patch/1107175/. However, I don't see a good
way to check if FEATURE_MDEV_DAEMON=y.
I could try to search for the daemon option in the help text
(`mdev 2>&1 | grep "runs mdev as daemon"`),
but this look a bit hackish to me.
>
>
> >> 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.
>
Regards,
Titouan
More information about the buildroot
mailing list