The following patch changes modprobe in module-init-tools-0.8
to use modules.dep.
Benefits:
- deletes a net of 594 lines of source code
- shrinks modprobe from 14kB to 10kB (stripped, dynamically linked),
which is useful for boot images
- should make modprobe as fast on systems with a lot of modules as
it was with the user level module loader,
- Restores the "include" command to the aliases file, which makes
it simpler to have separate files for automatically generated
aliases and user customizations.
- minor: eliminates ELF dependence from modprobe user level code
Drawbacks:
- It makes modprobe require that depmod had been run at some
point (although it isn't necessary to put depmod on a boot
image to use modprobe; you just need it when you want to add
a module that you want modprobe to know about). The current
depmod implementation is bigger than 594 lines of code, but
also generates hardware device tables, so systems that do
hardware autoconfiguration this way currently need depmod anyhow.
- I have not tested these changes much, because the in-kernel
module loader reports "memory allocation failure" for many
modules that I try to load. This does not appear to be
related to my changes.
- I do not currently see a positive balance of real benefits
to putting the module linker in unswappable kernel memory.
If you're running a system with a user level module loader,
you are probably better off staying with that.
Note to lmkl readers: this patch is again
module-init-tools-0.8.dwmw2, which is a modification done by David
Woodhouse of module-init-tools-0.7. It is not an official release,
and it requires a kernel patch which changes the system call interface
for loading modules (to pass the module name). I am posting a patch
against it instead of 0.7 because I don't want people applying this
patch and then breaking their systems due to the interface change. I
am also attaching David's patches to this message (after checking with
him by email), but please do not refer to David's changes or mine as
releases of module-init-tools, as they both depend on David's kernel
changes, which may or may not be integrated into Linus's future
releases.
--
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:36 EST