1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
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.
|
