~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~ [ freetext search ] ~ [ file search ] ~

Linux Cross Reference
Linux/Documentation/kmod.txt

Version: ~ [ 2.4.0 ] ~
Architecture: ~ [ i386 ] ~ [ alpha ] ~ [ m68k ] ~ [ mips ] ~ [ ppc ] ~ [ sparc ] ~ [ sparc64 ] ~

  1 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 <kaos@ocs.com.au> 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.

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~ [ freetext search ] ~ [ file search ] ~

This page was automatically generated by the LXR engine.
Visit the LXR main site for more information.