Managing Modules

When using a modular kernel, special tools are required to manage the modules. Modules must be loaded and unloaded, and it would be nice if that were done as automatically as possible. We also need to be able to pass necessary parameters to modules when we load themthings such as memory addresses and interrupts. (That information varies from module to module, so you will need to look at the documentation for your modules to determine what, if any, information needs to be passed to it.) In this section, we will cover the tools provided to manage modules and then look at a few examples of using them.

Linux provides the following module management tools for our use. All these commands (and modprobe.conf) have man pages:

lsmod This command lists the loaded modules. It is useful to pipe this through theiess command because the listing is usually more than one page long.

insmod This command loads the specified module into the running kernel. If a module name is given without a full path, the default location for the running kernel, /lib/modules/*/, will be searched. Several options are offered for this commandthe most useful is -f, which forces the module to be loaded.

rmmod This command unloads (removes) the specified module from the running kernel. More than one module at a time can be specified.

modprobe A more sophisticated version of insmod and rmmod, it uses the dependency file created by depmod and automatically handles loading, or with the -r option, removing modules. There is no force option, however. A useful option to modprobe is t, which causes modprobe to cycle through a set of drivers until it finds one that matches your system. If you were unsure of what module would work for your network card, you would use this command:

# modprobe -t net

The term net is used because that is the name of the directory (/lib/modules/*/kernel/net) where all the network drivers are kept. It will try each one in turn until it loads one successfully.

modinfo This will query a module's object file and provide a list of the module name, author, license, and any other information that is there. It often is not very useful.

depmod This program creates a dependency file for kernel modules. Some modules need to have other modules loaded first; that is, they "depend" on the other modules. (A lot of the kernel code is like this because it eliminates redundancy in the code base.) During the boot process, one of the startup files contains the command depmod -a and it is run every time you boot to recreate the file /lib/modules/*/modules.dep. If you make changes to the file /etc/modprobe.conf, run depmod -a manually. The depmod command, its list of dependencies, and the /etc/modprobe.conf file enable kernel modules to be automatically loaded as needed.

/etc/modprobe.conf This is not a command, but a file that controls how modprobe and depmod behave; it contains kernel module variables. Although the command syntax can be quite complex, most actual needs are very simple. The most common use is to alias a module and then pass it some parameters. For example, in the following code, we alias a device name (from devices.txt) to a more descriptive word and then pass some information to an associated module. The i2c-dev device is used to read the CPU temperature and fan speed on our system. These lines for /etc/modprobe.conf were suggested for our use by the program's documentation. We added them with a text editor.

alias char-major-89 i2c-dev options eeprom ignore=2,0x50,2,0x51,2,0x52

A partial listing of lsmod is shown here, piped through the less command, allowing us to view it a

page at a time:

# lsmod | less



Used by

parport pc





Used by

parport pc








2 parport







The list is actually much longer, but here we see that the input module is being used by the joydev (joystick device) module, but the joystick module is not being used. This computer has a joystick port that was autodetected, but no joystick is connected. A scanner module is also loaded, but because the USB scanner is unplugged, the module is not being used. You would use the lsmod command to determine whether a module was loaded and what other modules were using it. If you examine the full list, you would see modules for all the devices attached to your computer.

To remove a module, joydev in this example, use

# rmmod joydev or

# modprobe -r joydev

A look at the output of lsmod would now show that it is no longer loaded. If we removed input as well, we could then use modprobe to load both input and joydev (one depends on the other, remember) with a simple

# modprobe joydev

If Ubuntu were to balk at loading a module (because it had been compiled using a different kernel version from what we are currently running; for example, the NVIDIA graphics card module), we could force it to load like this:

# insmod -f nvidia

We would ignore the complaints (error messages) in this case if the kernel generated any.

In Chapter 10, "Multimedia Applications," we talked about loading a scanner module; in the example there, we manually loaded the scanner module and passed it the vendor ID. The scanner was not included in the lookup list because it is not supported by the GPL scanner programs; as a result, the scanner module was not automatically detected and loaded. However, the scanner will work with a closed-source application after the module is loaded. Automatic module management is nice when it works, but sometimes it is necessary to work with modules directly.


Was this article helpful?

0 0

Post a comment