1 |
1275 |
phoenix |
Kmod: The Kernel Module Loader
|
2 |
|
|
Kirk Petersen
|
3 |
|
|
|
4 |
|
|
Kmod is a simple replacement for kerneld. It consists of a
|
5 |
|
|
request_module() replacement and a kernel thread called kmod. When the
|
6 |
|
|
kernel requests a module, the kmod wakes up and execve()s modprobe,
|
7 |
|
|
passing it the name that was requested.
|
8 |
|
|
|
9 |
|
|
If you have the /proc filesystem mounted, you can set the path of
|
10 |
|
|
modprobe (where the kernel looks for it) by doing:
|
11 |
|
|
|
12 |
|
|
echo "/sbin/modprobe" > /proc/sys/kernel/modprobe
|
13 |
|
|
|
14 |
|
|
To periodically unload unused modules, put something like the following
|
15 |
|
|
in root's crontab entry:
|
16 |
|
|
|
17 |
|
|
0-59/5 * * * * /sbin/rmmod -a
|
18 |
|
|
|
19 |
|
|
Kmod only loads modules. Kerneld could do more (although
|
20 |
|
|
nothing in the standard kernel used its other features). If you
|
21 |
|
|
require features such as request_route, we suggest that you take
|
22 |
|
|
a similar approach. A simple request_route function could be called,
|
23 |
|
|
and a kroute kernel thread could be sent off to do the work. But
|
24 |
|
|
we should probably keep this to a minimum.
|
25 |
|
|
|
26 |
|
|
Kerneld also had a mechanism for storing device driver settings. This
|
27 |
|
|
can easily be done with modprobe. When a module is unloaded, modprobe
|
28 |
|
|
could look at a per-driver-configurable location (/proc/sys/drivers/blah)
|
29 |
|
|
for device driver settings and save them to a file. When a module
|
30 |
|
|
is loaded, simply cat that file back to that location in the proc
|
31 |
|
|
filesystem. Or perhaps a script could be a setting in /etc/modules.conf.
|
32 |
|
|
There are many user-land methods that will work (I prefer using /proc,
|
33 |
|
|
myself).
|
34 |
|
|
|
35 |
|
|
If kerneld worked, why replace it?
|
36 |
|
|
|
37 |
|
|
- kerneld used SysV IPC, which can now be made into a module. Besides,
|
38 |
|
|
SysV IPC is ugly and should therefore be avoided (well, certainly for
|
39 |
|
|
kernel level stuff)
|
40 |
|
|
|
41 |
|
|
- both kmod and kerneld end up doing the same thing (calling modprobe),
|
42 |
|
|
so why not skip the middle man?
|
43 |
|
|
|
44 |
|
|
- removing kerneld related stuff from ipc/msg.c made it 40% smaller
|
45 |
|
|
|
46 |
|
|
- kmod reports errors through the normal kernel mechanisms, which avoids
|
47 |
|
|
the chicken and egg problem of kerneld and modular Unix domain sockets
|
48 |
|
|
|
49 |
|
|
|
50 |
|
|
Keith Owens December 1999
|
51 |
|
|
|
52 |
|
|
The combination of kmod and modprobe can loop, especially if modprobe uses a
|
53 |
|
|
system call that requires a module. If modules.dep does not exist and modprobe
|
54 |
|
|
was started with the -s option (kmod does this), modprobe tries to syslog() a
|
55 |
|
|
message. syslog() needs Unix sockets, if Unix sockets are modular then kmod
|
56 |
|
|
runs "modprobe -s net-pf-1". This runs a second copy of modprobe which
|
57 |
|
|
complains that modules.dep does not exist, tries to use syslog() and starts yet
|
58 |
|
|
another copy of modprobe. This is not the only possible kmod/modprobe loop,
|
59 |
|
|
just the most common.
|
60 |
|
|
|
61 |
|
|
To detect loops caused by "modprobe needs a service which is in a module", kmod
|
62 |
|
|
limits the number of concurrent kmod issued modprobes. See MAX_KMOD_CONCURRENT
|
63 |
|
|
in kernel/kmod.c. When this limit is exceeded, the kernel issues message "kmod:
|
64 |
|
|
runaway modprobe loop assumed and stopped".
|
65 |
|
|
|
66 |
|
|
Note for users building a heavily modularised system. It is a good idea to
|
67 |
|
|
create modules.dep after installing the modules and before booting a kernel for
|
68 |
|
|
the first time. "depmod -ae m.n.p" where m.n.p is the new kernel version.
|