Loading Drivers Automatically

The Linux kernel includes a configuration option called kernel module loader. If this option is compiled into the kernel, it will attempt to load modules on an as-needed basis. For instance, if you try to play an audio file, the kernel will attempt to load the appropriate sound card drivers for your system. In order for this feature to work, though, the kernel needs information on which modules to load for specific tasks.

The /etc/modules.conf file is the master control file for automatic handling of kernel modules. It's also used by insmod, modprobe, and depmod, although these tools aren't as dependent upon modules.conf as is the kernel module auto-loader. The modules.conf file is a text file that contains a series of lines that provide information on the modules to load for specific device types (such as sound or SCSI devices), options to pass to those modules, and so on. Listing 1.1 shows a simple modules.conf

Listing 1.1: A Sample modules.conf File alias ethO tulip alias eth1 via-rhine post-install via-rhine /usr/local/bin/setup-eth1 alias char-major-10-219 mwave options mwave dspirq=10 dspio=0x130 uartirq=3 uartio=0x2f8

Debian uses a variant on this approach: It uses an /etc/modutils directory tree that contains a series of files for individual devices. (Most drivers are defined in files in /etc/modutils/arch.) After editing a file in this directory or creating a new one for a new device, type update-modules to update the module information, creating a new /etc/modules.conf file.

The modules.conf file supports a fairly large number of features, including conditional statements to configure certain drivers only if certain preconditions exist, such as only if the system is running a particular kernel version. The features illustrated by Listing \A_ will accomplish a great deal, though. These features are alias The alias keyword at the start of a line maps a specific device type, such as an Ethernet interface, to a specific driver. The first two lines of Listing 1.1, for instance, tell Linux to use the tulip driver for ethO and the via-rhine driver for eth1. Not all device names are intuitively obvious, though; for instance, the fourth line of Listing 1.1 tells the system to use the mwave driver for char-major-10-219. This driver is for IBM's Mwave chipset, which provides both audio and modem functionality. It's mapped to specific major and minor device numbers rather than a device name like ethO or scsi.

options You can pass options to drivers loaded as modules by including an options line in the modules.conf file. Listing 1.1 illustrates this capability with an options line for the mwave module. After the keyword options and the module name, the options passed to the module are very module-specific. You should consult your driver's documentation to learn what options it supports.

Outside Command Specifications Listing 1.1's post-install specification is one of several keywords that can be used to run arbitrary programs before or after installing or uninstalling modules. The other keywords are pre-install, pre-remove, and post-remove. Begin a line with the keyword, then provide the module name, and then provide the external command. You could use this feature to automate features such as bringing up a network interface that's frequently not installed (for example, a USB network interface on a laptop) or to adjust mixer settings after loading a sound card's drivers.

If you're having problems with a driver for a device that should be supported by Linux out of the box, your best bet is to first use insmod or modprobe to try to get the appropriate module loaded. Checking on loaded modules in /proc/modules, as described in the upcoming section, "Demystifying the /proc Filesystem," can also be a useful diagnostic tool. Once you've discovered what modules need to be loaded, try creating entries for these modules in /etc/modules.conf. Assuming your kernel includes module auto-loader support, the drivers should then load automatically when you next boot or attempt to use the drivers in question.

If you've obtained drivers from a third-party source and need to integrate them into your system, the documentation that came with those drivers should include information on /etc/module.conf entries. Add those entries, and be sure your current modules.conf file doesn't include conflicting entries. If it does, comment those entries out by adding a hash mark (#) to the start of each conflicting line.

When modules depend upon other modules, it's important that /etc/modules.conf includes alias lines for all of the dependent modules. The /proc/modules pseudo-file can be very useful in finding all of these modules, assuming you've gotten the device working via insmod or modprobe. Type cat/proc/modules, and you'll see a series of

This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to regist* output lines resembling the following: parport 22528 2 (autoclean) [parport_pc Ip]

The Ismod command produces similar output. The module names in square brackets ([]) at the end of the line are those that depend upon the main module (parport in this case). In other words, any alias line loading a driver for Ip or parport_pc in this example must be preceded in /etc/modules.conf by a line that loads parport.

Tip If you create an /etc/modules.conf file and it doesn't seem to work, try manually loading each module the file references with insmod (not modprobe). If you receive a dependency error message when loading a module, track down the out-of-order or missing module and change or add its reference in modules.conf.

Team LIB

0 0

Post a comment