RFD: Rework/extending functionality of mdev

[James Bowlin]

TL;DR: the current busybox (or my code) seems to be broken on one
or two systems out of thousands; crucial modules don't get loaded
using hotplug + coldplug.  Please give me a runtime option so I
can give my users a boot-time option to try the new approach.

On Fri, Mar 13, 2015 at 02:04 PM, Guillermo Rodriguez Garcia said:
> Perhaps my message is not getting across. What I am saying is
> that I am not sure your suggestion is actually something others
> would find useful. Other than the fact that you like it
> yourself I don't see a lot of enthusiasm around about it.

I've been following this thread on and off and I feel *very*
enthusiastic about Harald Becker's approach.  I kept silent
because there was already so much posting and I figured everyone
would finally get on board with Harald's suggestions.

I admit I build my own busybox but I would *hate* to have to make
this choice at build-time.  I want to  give my users a boot-time
option ("failsafe" or something like that) to go back to the
older, slower way.  Or maybe make the older way the default and
give them an option to use the new approach.  Making it a
build-time option is extremely hubristic; it assumes both the
current code and the new code are perfect.

I have a few users (out of many thousands) who have trouble
loading modules they need using the conventional busybox tools.
I enable hotplugging and then coldplug, loading everything from:

   /sys/devices -name modalias -exec cat '{}' + 2>/dev/null

I've also used:

    find /sys/devices -name uevent -exec sed -n \
        's/^MODALIAS=//p' '{}' + 2>/dev/null \

But after filtering through "sort -u" the outputs of the find
commands are identical.  So I have a failsafe fallback that
loads all modules from: /lib/modules/$(uname -r)

The alias for the needed module shows up in those lists but
they don't always get loaded.  Oddly enough the crucial modules
does *not* show up when I pipe that output through:

    | xargs modprobe -a -D

But it shows up when I use the Debian modprobe.  The crucial
module does get loaded on my system when I use:

    | xargs modprobe -a

This is a strange bug in "modprobe -a -D" but it does not explain
the bug that causes failure to load certain modules via hotplug +
coldplug.  Maybe the bug is in my code; maybe the bug is in
busybox.  I don't know for sure.  My guess is it is a glitch in
the hotplugging.  I have not heard back from the user who
reported the problem.  The next test would be to keep doing the
cold-plugging and see if that fixes the problem.

Last year I discovered and reported a bug in the small modprobe
when it did not load certain modules during a coldplug.  The bug
was fixed but I have since moved to the large modprobe.  I'm
hoping that a more streamlined and orderly hotplug solution in
busybox will fix the problem above so I don't have to ever resort
to loading all modules.  If Harald's solution is a runtime option
then I could make it a boot-time option and test it on thousands
of machines.  ISTM this is the only sane approach.

I also liked this suggestion from Natanael:

On Fri, Mar 13, 2015 at 10:33 AM, Natanael Copa said:
> While solving this, I would also like to find a way to load the
> MODALIAS without forking.

But I don't think this is the answer:

> One option is to add modprobe -i which reads modaliases from
> stdin with a timeout. Maybe that is a lower hanging fruit than
> mdev -i?

Since ISTM that can be handled with xargs (does that fork a
lot?). ISTM there is a lot of forking in the find commands as
illustrated above.  I think we would need to use:

    modprobe --find-modalias /sys/devices

where the user gets to define which directory is searched.  There
could also be a:

    modprobe --find-uevent /sys/devices

where the grep/sed is built-in as well.  OTOH, perhaps these
would be a nightmare code-wise.  I'd sure like to know if this
approach is significantly faster or not.

BTW: I try to time most things in my initrd init script to keep
an eye on what slows things down so we can stay as speedy as
possible.  I use:

    cut -d" " -f22 /proc/self/stat 

to get the time in hundredths of a second since the kernel
booted.  But this itself and the associated arithmetic is not
free time-wise.  So I disable most of the timing when I'm not in
debug mode.  If there is a better/faster way to get the time to
hundredths of a second or better, PLMK.  A shell built-in would
make me very happy.  Perhaps this seems way OT but ISTM that
precise timing is essential for comparing how fast things are
when the overall time is only a second or two.  If there is a
better way to get the time, PLMK; otherwise I suggest people use
the cut command above for timing how long things take.


Peace, James