Книга: Fedora™ Unleashed, 2008 edition

Managing Modules

Managing Modules

With 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. You also need to be able to pass necessary parameters to modules when you load them — things such as memory addresses and interrupts. (That information varies from module to module, so you need to look at the documentation for your modules to deter mine what, if any, information needs to be passed to it.) This section covers the tools provided to manage modules and then look at a few examples of using them.

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

lsmod — This command lists the loaded modules. It is useful to pipe this through the less 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/*/, is searched. Several options are offered for this command — the 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 tries each one in turn until it loads one successfully.

modinfo — This queries a module's object file and provides 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 re-create the file /lib/modules/*/modules.dep. If you make changes to the /etc/modprobe.conf file, 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, a device name (from devices.txt) is aliased to a more descriptive word and then some information is passed to an associated module. The i2c-dev device is used to read the CPU temperature and fan speed on the system. These lines for /etc/modprobe.conf were suggested for use by the program's documentation. They were added 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, so that you can view it a page at a time:

# lsmod | less
Module      Size Used by
parport_pc 19392 1
lp          8236 0
parport    29640 2 parport_pc,lp
autofs4    10624 0
sunrpc    101064 1

The list is actually much longer, but here you can 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 auto-detected, 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 examined 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 you removed input as well, you could then use modprobe to load both input and joydev (one depends on the other, remember) with a simple:

# modprobe joydev

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

# insmod -f nvidia

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

Chapter 7, "Multimedia," talked about loading a scanner module; in the example there, the scanner module was loaded manually and the vendor ID was passed to it. 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 works 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.

Оглавление книги


Генерация: 1.711. Запросов К БД/Cache: 3 / 0
поделиться
Вверх Вниз