[PATCH] Remove Documentation/kmod.txt

From: Rusty Russell <rusty@rustcorp.com.au>

Please delete Documentation/kmod.txt: it's entirely outdated and misleading.

I thought about rewriting it, but there's not much to add beyond what's in
the CONFIG_KMOD's help text.

Documentation/kmod.txt

-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.