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