| Kmod: The Kernel Module Loader |
| Kirk Petersen |
| |
| Kmod is a simple replacement for kerneld. It consists of a |
| request_module() replacement and a kernel thread called kmod. When the |
| kernel requests a module, the kmod wakes up and execve()s modprobe, |
| passing it the name that was requested. |
| |
| If you have the /proc filesystem mounted, you can set the path of |
| modprobe (where the kernel looks for it) by doing: |
| |
| echo "/sbin/modprobe" > /proc/sys/kernel/modprobe |
| |
| To periodically unload unused modules, put something like the following |
| in root's crontab entry: |
| |
| 0-59/5 * * * * /sbin/rmmod -a |
| |
| Kmod only loads modules. Kerneld could do more (although |
| nothing in the standard kernel used its other features). If you |
| require features such as request_route, we suggest that you take |
| a similar approach. A simple request_route function could be called, |
| and a kroute kernel thread could be sent off to do the work. But |
| we should probably keep this to a minimum. |
| |
| Kerneld also had a mechanism for storing device driver settings. This |
| can easily be done with modprobe. When a module is unloaded, modprobe |
| could look at a per-driver-configurable location (/proc/sys/drivers/blah) |
| for device driver settings and save them to a file. When a module |
| is loaded, simply cat that file back to that location in the proc |
| filesystem. Or perhaps a script could be a setting in /etc/modules.conf. |
| There are many user-land methods that will work (I prefer using /proc, |
| myself). |
| |
| If kerneld worked, why replace it? |
| |
| - kerneld used SysV IPC, which can now be made into a module. Besides, |
| SysV IPC is ugly and should therefore be avoided (well, certainly for |
| kernel level stuff) |
| |
| - both kmod and kerneld end up doing the same thing (calling modprobe), |
| so why not skip the middle man? |
| |
| - removing kerneld related stuff from ipc/msg.c made it 40% smaller |
| |
| - kmod reports errors through the normal kernel mechanisms, which avoids |
| the chicken and egg problem of kerneld and modular Unix domain sockets |
| |
| |
| Keith Owens <kaos@ocs.com.au> December 1999 |
| |
| The combination of kmod and modprobe can loop, especially if modprobe uses a |
| system call that requires a module. If modules.dep does not exist and modprobe |
| was started with the -s option (kmod does this), modprobe tries to syslog() a |
| message. syslog() needs Unix sockets, if Unix sockets are modular then kmod |
| runs "modprobe -s net-pf-1". This runs a second copy of modprobe which |
| complains that modules.dep does not exist, tries to use syslog() and starts yet |
| another copy of modprobe. This is not the only possible kmod/modprobe loop, |
| just the most common. |
| |
| To detect loops caused by "modprobe needs a service which is in a module", kmod |
| limits the number of concurrent kmod issued modprobes. See MAX_KMOD_CONCURRENT |
| in kernel/kmod.c. When this limit is exceeded, the kernel issues message "kmod: |
| runaway modprobe loop assumed and stopped". |
| |
| Note for users building a heavily modularised system. It is a good idea to |
| create modules.dep after installing the modules and before booting a kernel for |
| the first time. "depmod -ae m.n.p" where m.n.p is the new kernel version. |