Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
LKM(4)			 BSD Kernel Interfaces Manual			LKM(4)

     lkm -- loadable kernel module facility

     Loadable kernel modules allow the system administrator to dynamically add
     and remove	functionality from a running system.  This ability also	helps
     software developers to develop new	parts of the kernel without constantly
     rebooting to test their changes.

     Various types of modules can be loaded into the system.  There are	sev-
     eral defined module types,	listed below, which can	be added to the	system
     in	a predefined way.  In addition,	there is a generic type, for which the
     module itself handles loading and unloading.

     The FreeBSD system	makes extensive	use of loadable	kernel modules,	and
     provides loadable versions	of most	filesystems, the NFS client and
     server, all the screen-savers, and	the iBCS2 and Linux emulators.	Mod-
     ules distributed with the system are found	in the /lkm directory.

     The lkm interface is used by performing ioctl(2) calls on the /dev/lkm
     device.  Normally all operations involving	Loadable Kernel	Modules	are
     handled by	the modload(8),	modunload(8), and modstat(8) programs.	Users
     should never have to interact with	/dev/lkm directly.

     System Call modules
     System calls may be replaced by loading new ones via the lkm interface.
     All system	calls may be replaced, but special care	should be taken	with
     the ioctl(2) system call, as it is	used to	load and unload	modules.

     When a system call	module is unloaded, the	system call which was replaced
     by	the loadable module is returned	to its rightful	place in the system
     call table.

     Virtual File System modules
     Virtual file systems may be added via the lkm interface.

     Device Driver modules
     New block and character device drivers may	be loaded into the system with
     LKM.  The major problem with loading a device driver is that the driver's
     device nodes must be exist	for the	devices	to be accessed.	 They are usu-
     ally created by instructing modload(8) to run an appropriate program when
     the driver	has been successfully loaded.

     Execution classes
     Also known	as image activators, execution classes are the mechanisms by
     which the execve(2) system	call is	able to	recognize an executable	file's
     format and	load it	into memory.

     Miscellaneous modules
     Miscellaneous modules are modules for which there are not currently well-
     defined or	well-used interfaces for extension.  Users are expected	to
     write their own loaders to	manipulate whatever kernel data	structures
     necessary to enable and disable the new module when it is loaded and un-

     /dev/lkm		      lkm interface device
     /lkm		      directory	containing module binaries shipped
			      with the system
     /usr/include/sys/lkm.h   file containing definitions of module types
     /usr/share/examples/lkm  example source code implementing two of the mod-
			      ule types

     modload(8), modstat(8), modunload(8)

     If	a module fails to initialize itself correctly, and the system is able
     to	detect this failure, it	will panic immediately.

     When system internal interfaces change, old modules often cannot detect
     this, and such modules when loaded	will often cause crashes or mysterious

     The lkm facility was originally implemented by Terrence R.	Lambert.
     Loadable filesystems were implemented by
     Garrett Wollman, and loadable execution classes were implemented by
     David Greenman,
     Soren Schmidt, and
     Garrett Wollman.

     The lkm facility was designed to be similar in functionality to the load-
     able kernel modules facility provided by SunOS 4.1.3.

FreeBSD	2.0		       January 17, 1996			   FreeBSD 2.0


Want to link to this manual page? Use this URL:

home | help