From a07fccd514e3ba059171f6b155fcda8468120918 Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Wed, 3 Sep 2003 11:13:47 -0700 Subject: [PATCH] [PATCH] Remove Documentation/kmod.txt From: Rusty Russell 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 | 68 ------------------------------------------ 1 file changed, 68 deletions(-) delete mode 100644 Documentation/kmod.txt diff --git a/Documentation/kmod.txt b/Documentation/kmod.txt deleted file mode 100644 index be1a9a5183ee4..0000000000000 --- a/Documentation/kmod.txt +++ /dev/null @@ -1,68 +0,0 @@ -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 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. -- 2.53.0