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.5.
Note that the examples in this section are from Linux 2.4. In Linux 2.6, the technical aspects of loading LKMs are considerably different, and the most visible manifestation of this is that the LKM file has a suffix of ".ko" instead of ".o". From the user point of view, it looks quite similar, though.
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 |
(In Linux 2.6, there is no /proc/ksyms. Use /proc/kallsyms instead; the format is like the output of nm: look for symbols labelled "t").
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 15. 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.
A common error is to try to insert an object file which is not an LKM. For example, you configure your kernel to have the USB core module bound into the base kernel instead of generated as an LKM. In that case, you end up with a file usbcore.o, which looks pretty much the same as the usbcore.o you would get if you built it as an LKM. But you can't insmod that file.
So do you get an error message telling you that you should have configured the kernel to make USB core function an LKM? Of course not. This is Unix, and explanatory error messages are seen as a sign of weakness. The error message is
$ insmod usbcore.o usbcore.o: couldn't find the kernel version this module was compiled for |
What insmod is telling you is that it looked in usbcore.o for a piece of information any legitimate LKM would have -- the kernel version with which the LKM was intended to be used -- and it didn't find it. We know now that the reason it didn't find it is that the file isn't an LKM. See Section 10.2 for information on how you can see what insmod is seeing and confirm that the file is not in fact an LKM.
If this is a module you created yourself with the intention of it being an LKM, the next question you have is: Why isn't an LKM? The most usual cause of this is that you did not include linux/module.h at the top of your source code and/or did not define the MODULE> macro. MODULE is intended to be set via the compile command (-DMODULE) and determine whether the compilation produces an LKM or an object file for binding into the base kernel. If your module is like most modern modules and can be built only as an LKM, then you should just define it in your source code (#define MODULE) before you include include/module.h.
So you've successfully loaded an LKM, and verified that via /proc/modules. But how do you know it's working? That's up to the LKM, and varies according to what kind of LKM it is, but here are some of the more common actions of an LKM upon being loaded.
The first thing a device driver LKM does after loading (which is what the module would do at boot time if it were bound into the base kernel) is usually to search the system for a device it knows how to drive. Just how it does this search varies from one driver to the next, and can usually be controlled by module parameters. But in any case, if the driver doesn't find any device it is capable of driving, it causes the load to fail. Otherwise, the driver registers itself as the driver for a particular major number and you can start using the device it found via a device special file that specifies that major number. It may also register itself as the handler for the interrupt level that the device uses. It may also send setup commands to the device, so you may see lights blink or something like that.
You can see that a device driver has registered itself in the file /proc/devices. You can see that the device driver is handling the device's interrupts in /proc/interrupts.
A nice device driver issues kernel messages telling what devices it found and is prepared to drive. (Kernel messages in most systems end up on the console and in the file /var/log/messages. You can also display recent ones with the dmesg program). Some drivers, however, are silent. A nice device driver also gives you (in kernel messages) some details of its search when it fails to find a device, but many just fail the load without explanation, and what you get is a list of guesses from insmod as to what the problem might have been.
A network device (interface) driver works similarly, except that the LKM registers a device name of its choosing (e.g. eth0) rather than a major number. You can see the currently registered network device names in /proc/net/dev
A filesystem driver, upon loading, registers itself as the driver for a filesystem type of a certain name. For example, the msdos driver registers itself as the driver for the filesystem type named msdos. (LKM authors typically name the LKM the same as the filesystem type it will drive).
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 an insmod of msdos.o, but before that does an insmod of fat.o, since you have to have fat.o loaded before you can load msdos.o.
The other major thing modprobe does for you is to find the object module containing the LKM given just the name of the LKM. For example, modprobe msdos might load /lib/2.4.2-2/fs/msdos.o. In fact, modprobe's argument may be a totally symbolic name that you have associated with some actual module. For example, modprobe eth0 loads the appropriate network device driver to create and drive your eth0 device, assuming you set that up properly in modules.conf. Check out the man pages for modprobe and the configuration file modules.conf (usually /etc/modules.conf) for details on the search rules modprobe uses.
modprobe is especially important because it is by default the program that the kernel module loader uses to load an LKM on demand. So if you use automatic module loading, you will need to set up modules.conf properly or things will not work. See Section 5.4.
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 either the kernel module loader, which is part of the Linux kernel, or the older version of it, a kerneld daemon.
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 one of the two automatic module loading facilities are available and uses it to cause the LKM to be loaded. The kernel then proceeds with the open.
Automatic kernel module loading is really not worth the complexity in most modern systems. It may make sense in a very small memory system, because you can keep parts of the kernel in memory only when you need them. But the amount of memory these modules uses is so cheap today that you will normally be a lot better off just loading all the modules you might need via startup scripts and leaving them loaded.
Red Hat Linux uses automatic module loading via the kernel module loader.
Both the kernel module loader and kerneld use modprobe, ergo insmod, to insert LKMs. See Section 5.3.
There is some documentation of the kernel module loader in the file Documentation/kmod.txt in the Linux 2.4 source tree. This section is more complete and accurate than that file. You can also look at its source code in kernel/kmod.c.
The kernel module loader is an optional part of the Linux kernel. You get it if you select the CONFIG_KMOD feature when you configure the kernel at build time.
When a kernel that has the kernel module loader needs an LKM, it creates a user process (owned by the superuser, though) that executes modprobe to load the LKM, then exits. By default, it finds modprobe as /sbin/modprobe, but you can set up any program you like as modprobe by writing its file name to /proc/sys/kernel/modprobe. For example:
# echo "sbin/mymodprobe" >/proc/sys/kernel/modprobe |
The kernel module loader passes the following arguments to the modprobe: Argument Zero is the full file name of modprobe. The regular arguments are -s, -k, and the name of the LKM that the kernel wants. -s is the user-hostile form of --syslog; -k is the cryptic way to say --autoclean. I.e. messages from modprobe will go to syslog and the loaded LKM will have the "autoclean" flag set.
The most important part of the modprobe invocation is, of course, the module name. Note that the "module name" argument to modprobe is not necessarily a real module name. It is often a symbolic name representing the role that module plays and you use an alias statement in modules.conf to tell what LKM gets loaded. For example, if your Ethernet adapter requires the 3c59x LKM, you would have probably need the line
alias eth0 3c59x |
When you try access a device and no device driver has registered to serve that device's major number, the kernel requests the module by the name block-major-N or char-major-N where N is the major number in decimal without leading zeroes.
When you try to access a network interface (maybe by running ifconfig against it) and no network device driver has registered to serve an interface by that name, the kernel requests the module named the same as the interface name (e.g. eth0). This applies to drivers for non-physical interfaces such as ppp0 as well.
When you try to access a socket in a protocol family which no protocol driver has registered to drive, the kernel requests the module named net-pf-N, where N is the protocol family number (in decimal without leading zeroes).
When you try to NFS export a directory or otherwise access the NFS server via the NFS system call, the kernel requests the module named nfsd.
The ATA device driver (named ide) loads the relevant drivers for classes of ATA devices by the names: ide-disk, ide-cd, ide-floppy, ide-tape, and ide-scsi.
The kernel module loader runs modprobe with the following environment variables (only): HOME=/; TERM=linux; PATH=/sbin:/usr/sbin:/bin:/usr/bin.
The kernel module loader was new in Linux 2.2 and was designed to take the place of kerneld. It does not, however, have all the features of kerneld.
In Linux 2.2, the kernel module loader creates the above mentioned process directly. In Linux 2.4, the kernel module loader submits the module loading work to Keventd and it runs as a child process of Keventd.
The kernel module loader is a pretty strange beast. It violates layering as Unix programmers generally understand it and consequently is inflexible, hard to understand, and not robust. Many system designers would bristle just at the fact that it has the PATH hardcoded. You may prefer to use kerneld instead, or not bother with automatic loading of LKMs at all.
kerneld is explained at length in the Kerneld mini-HOWTO, available from the Linux Documentation Project.
kerneld is a user process, which runs the kerneld program from the modutils package. kerneld sets up an IPC message channel with the kernel. When the kernel needs an LKM, it sends a message on that channel to kerneld and kerneld runs modprobe to load the LKM, then sends a message back to the kernel to say that it is done.
Each loaded LKM has an autoclean flag which can be set or unset. You control this flag with parameters to the init_module system call. Assuming you do that via insmod, you use the --autoclean option.
You can see the state of the autoclean flag in /proc/modules. Any LKM that has the flag set has the legend autoclean next to it.
The purpose of the autoclean flag is to let you automatically remove LKMs that haven't been used in a while (typically 1 minute). So by using automatic module loading and unloading, you can keep loaded only parts of the kernel that are presently needed, 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 module loader processes. Just load everything you might need via an initialization script and keep it loaded.
There is a form of the delete_module system call that says, "remove all LKMs that have the autoclean flag set and haven't been used in a while." Kerneld typically calls this once per minute. You can call it explicitly with an rmmod --all command.
As the kernel module loader does not do any removing of LKMs, if you use that you might want to have a cron job that does a rmmod --all periodically.
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 does 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.
Do not confuse use count with "dependencies", which are described below.
Here is another example, with more information:
lp 5280 0 (unused) parport_pc 7552 1 parport 7600 1 [lp parport_pc] |
You cannot unload an LKM that has dependencies. But you can remove those dependencies by unloading the dependent LKMs.
The "(unused)" legend means the LKM has never been used, i.e. it has never been in a state where it could not be unloaded. The kernel tracks this information for one simple reason: to assist in automatic LKM unloading policy. In a system where LKMs are loaded and unloaded automatically (see Section 5.4), you don't want to automatically load an LKM and then, before the guy who needed it loaded has a chance to use it, unload it because it is not in use.
Here is something you won't normally see:
mydriver 8154 0 (deleted) |
There are similar statuses "initializing" and "uninitialized".
The legend "(autoclean)" refers to the autoclean flag, discussed in Section 5.4.
The LKM world is flexible enough that the files you need to load could live just about anywhere on your system, but there is a convention that most systems follow: The LKM .o files are in the directory /lib/modules, divided into subdirectories. There is one subdirectory for each version of the kernel, since LKMs are specific to a kernel (see Section 6). Each subdirectory contains a complete set of LKMs.
The subdirectory name is the value you get from the uname --release command, for example 2.2.19. Section 6.3 tells how you control that value.
When you build Linux, a standard make modules and make modules_install should install all the LKMs that are part of Linux in the proper release subdirectory.
If you build a lot of kernels, another organization may be more helpful: keep the LKMs together with the base kernel and other kernel-related files in a subdirectory of /boot. The only drawback of this is that you cannot have /boot reside on a tiny disk partition. In some systems, /boot is on a special tiny "boot partition" and contains only enough files to get the system up to the point that it can mount other filesystems.