Kernel module loading

In my previous blog post, I deliberated on the direction of Quirky and the merits of a full install versus frugal or live-CD:
http://bkhome.org/news/201512/where-am-i-going.html

A full install means that there is no need for an initrd. I see the initrd, or initramfs, as an unecessary extra step at bootup. I gave the ability to not have an initrd as one good reason for doing a full install.
Note though, other distros such as Debian and Ubuntu do have an initrd with a full install, a massive one. They throw in the entire collection of modules (which remain duplicated in the main f.s.).

I have rather wistfully thought that without an initrd, the kernel should be capable of automatically loading all modules, without need for udev and without needing to replay uevents. Yes, theoretically the kernel could be made to do that. It does everything required, such as automatically creating /dev device nodes, load firmware, and able to match module aliases to the actual hardware.

Yeah, except that this is more of a hopeful statement, rather than fact.
In theory, the kernel should be able to load all of the modules, without needing udev (or eudev or any other helper). Yes, except that it doesn't.

Booting Quirky Werewolf 7.4, 88 modules get loaded. I determine that by running "lsmod | wc -l" and subtracting 2. The script /etc/rc.d/rc.sysinit replays kernel uevents to achieve this. Puppy Linux has the same code and will load the same modules.

udev at bootup
We have to replay the uevents in our rc.sysinit script. Up until now, it has been rather complicated -- rc.sysinit has a mix of scanning through /sys and running "uedadm trigger ...". Messy. Actually, just this alone will load all the modules (after launching udevd):

udevadm trigger --action=add

<

...in fact, it loads one-more than before, 89 modules. Years ago, when I was last investigating this, I seem to recall problems with such a wide sweeping replay -- maybe it was slow, or hung. Anyway, running eudev 1.10 on my laptop now, it works, and fast.

I tested this, which it seems will narrow the replay to uevents that do not already have a loaded driver:

udevadm trigger --action=add --attr-nomatch=driver

<

Then I read somewhere that doing it in two steps is good:

udevadm trigger --action=add --attr-nomatch=driver --type=subsystems

udevadm trigger --action=add --attr-nomatch=driver --type=devices

<

The main problem with figuring all of this out is the very poor documentation.
I just happened to come across a post that described "--attr-nomatch=driver". I read some posts that you should not use "--action=add" -- yet I have to, otherwise most modules do not load.

The idea of not using udev at all at bootup, for coldplug module loading, is just not the way the kernel is designed these days. We might as well launch udevd and run "udevadm trigger ..." at bootup, as the daemon is then in place for future hotplugging.

Bootup without udev
Just "thinking out loud" here. We could take the kernel conceptually back a few years, and configure it to use an external "uevent helper" script to load modules (by calling 'modprobe').
One reason this kind of thing was done away with, I think, is because of the huge number of parallel processes that can be created, as the kernel spews out uevents.

I decided to experiment. The 4.2.6 kernel in Werewolf 7.4 is configured without support for a "uevent helper", so I compiled 4.2.8 and enabled that. Set it to /sbin/hotplug.

I got it working, kind of. The problem is, I could not get it to load anywhere near 88 modules.

Conclusion
Udev is here to stay.

Tags: linux