The basic programs for inserting and removing LKMs are insmod and rmmod. See their man pages for details.
Inserting an LKM is conceptually easy: Just type, as superuser, a command like
insmod serial.o |
However, I would be misleading you if I said the command just works. It is very common, and rather maddening, for the command to fail either with a message about a module/kernel version mismatch or a pile of unresolved symbols.
If it does work, though, the way to prove to yourself that you know what you're doing is to look at /proc/modules as described in Section 5.3.
Now lets look at a more difficult insertion. If you try
insmod msdos.o |
msdos.o: unresolved symbol fat_date_unix2dos msdos.o: unresolved symbol fat_add_cluster1 msdos.o: unresolved symbol fat_put_super ... |
This is because msdos.o contains external symbol references to the symbols mentioned and there are no such symbols exported by the kernel. To prove this, do a
cat /proc/ksyms |
How do you get it into the list? By loading another LKM, one which defines those symbols and exports them. In this case, it is the LKM in the file fat.o. So do
insmod fat.o |
insmod msdos.o |
msdos 5632 0 (unused) fat 30400 0 [msdos] |
How did I know fat.o was the module I was missing? Just a little ingenuity. A more robust way to address this problem is to use depmod and modprobe instead of insmod, as discussed below.
When your symbols look like "fat_date_unix2dos_R83fb36a1", the problem may be more complex than just getting prerequisite LKMs loaded. See Section 6.
When the error message is "kernel/module version mismatch," see Section 6.
Often, you need to pass parameters to the LKM when you insert it. For example, a device driver wants to know the address and IRQ of the device it is supposed to drive. Or the network driver wants to know how much diagnostic tracing you want it to do. Here is an example of that:
insmod ne.o io=0x300 irq=11 |
Here, I am loading the device driver for my NE2000-like Ethernet adapter and telling it to drive the Ethernet adapter at IO address 0x300, which generates interrupts on IRQ 11.
There are no standard parameters for LKMs and very few conventions. Each LKM author decides what parameters insmod will take for his LKM. Hence, you will find them documented in the documentation of the LKM. This HOWTO also compiles a lot of LKM parameter information in Section 13. For general information about LKM parameters, see Section 8.
To remove an LKM from the kernel, the command is like
rmmod ne |
There is a command lsmod to list the currently loaded LKMs, but all it does is dump the contents of /proc/modules, with column headings, so you may just want to go to the horse's mouth and forget about lsmod.
Once you have module loading and unloading figured out using insmod and rmmod, you can let the system do more of the work for you by using the higher level program modprobe. See the modprobe man page for details.
The main thing that modprobe does is automatically load the prerequisites of an LKM you request. It does this with the help of a file that you create with depmod and keep on your system.
Example:
modprobe msdos |
This performs insmod msdos.o, but before that does insmod fat.o, since you have to have fat.o loaded before you can load msdos.o.
Note that with modprobe, you don't name the object module; you name the module (and modprobe infers the name of the object module, e.g. "msdos.o" from "msdos").
depmod scans your LKM object files (typically all the .o files in the appropriate /lib/modules subdirectory) and figures out which LKMs prerequire (refer to symbols in) other LKMs. It generates a dependency file (typically named modules.dep), which you normally keep in /lib/modules for use by modprobe.
You can use modprobe to remove stacks of LKMs as well.
Via the LKM configuration file (typically /etc/modules.conf), you can fine tune the dependencies and do other fancy things to control LKM selections. And you can specify programs to run when you insert and remove LKMs, for example to initialize a device driver.
If you are maintaining one system and memory is not in short supply, it is probably easier to avoid modprobe and the various files and directories it needs, and just do raw insmods in a startup script.
You can cause an LKM to be loaded automatically when the kernel first needs it. You do this with the Kerneld (kerneld) daemon, which makes use of a special kernel function designed for this purpose.
As an example, let's say you run a program that executes an open system call for a file in an MS-DOS filesystem. But you don't have a filesystem driver for the MS-DOS filesystem either bound into your base kernel or loaded as an LKM. So the kernel does not know how to access the file you're opening on the disk.
The kernel recognizes that it has no filesystem driver for MS-DOS, but that the Kerneld daemon is running, so it notifies Kerneld that it needs a filesystem driver for MS-DOS. Kerneld knows where you keep your LKM of the MS-DOS filesystem driver, so it loads it and tells the kernel it did. The kernel then proceeds with the open.
Kerneld is explained at length in the Kerneld mini-HOWTO, available from the Linux Documentation Project.
Kerneld also removes modules that haven't been used in a while (typically 1 minute). So by using Kerneld, you can keep only parts of the kernel that are presently needed loaded, and save memory.
This is less important than it once was, with memory being much cheaper. If you don't need to save memory, you shouldn't bother with the complexity of Kerneld. Just load everything you might need via an initialization script and keep it loaded.
Kerneld uses modprobe, ergo insmod, to insert LKMs.
To see the presently loaded LKMs, do
cat /proc/modules |
You see a line like
serial 24484 0 |
The left column is the name of the LKM, which is normally the name of the object file from which you loaded it, minus the ".o" suffix. You can, however, choose any name you like with an option on insmod.
The "24484" is the size in bytes of the LKM in memory.
The "0" is the use count. It tells how many things presently depend on the LKM being loaded. Typical "things" are open devices or mounted fileystems. It is important because you cannot remove an LKM unless the use count is zero. The LKM itself maintains this count, but the module manager uses it to decide whether to permit an unload.
There is an exception to the above description of the use count. You may see -1 in the use count column. What that means is that this LKM rdoes not use use counts to determine when it is OK to unload. Instead, the LKM has registered a subroutine that the module manager can call that will return an indication of whether or not it is OK to unload the LKM. In this case, the LKM ought to provide you with some custom interface, and some documentation, to determine when the LKM is free to be unloaded.