> The introduction of kmod eliminated the 0.01 ms fork() overhead, and
> consequently required each module to be loaded sequentially. This
> imposes an overhead of 10 to 20 milliseconds times the number of
> modules, which is asymptotically worse than what it replaced. A feature
> of kmod intended to address that placed all modules into a single file,
> which would actually make things faster. However, none of our users use
> it and all of our users would suffer from it.
This paragraph is full of misconceptions.
a) kmod didn't eliminate the fork overhead, but rather the exec one (and not only the time of the exec syscall, but also the config parsing, index loading, etc). It's particularly important when the module is already loaded and all you want is to check it is actually loaded.
b) there's no way to load modules in parallel. Please check the kernel implementation of module_init before stating things like above. Exec'ing several instances of modprobe doesn't mean you are loading the modules in parallel.
c) Exec'ing modprobe is no better than using the library. Saying that while exec'ing modprobe you have all modules in "10ms ~ 20ms" vs "10ms ~ 20ms times the number of modules" is not true. And the use of "which is asymptotically worse than what it replaced" shows intention to distort data. Please, publish your measurements.
d) There's no such "all modules in a single file" feature in kmod. And if it had it would have *nothing* to do to any of the problems you mentioned. What udev uses is a cached version of resources, meaning config, index, etc. To be fair, there's such an item in the TODO of kmod, but it was from its early days and I'm totally baffled about you thinking that was implemented.
> In addition, the manner in which kmod was integrated has implications
> beyond speed regressions. The use of kmod by udev permits a buggy kernel
> module (possibly interacting with bad hardware) to hang in module_init.
Do you mean the firmware issue? It was fixed in different places, both in kernel and udev. Not an issue anymore. Otherwise, exec'ing modprobe doesn't give you any other guarantee the module will not fail on module's init.