InformIT Online Books > LPI Linux Certification in a Nutshell

Book: LPI Linux Certification in a Nutshell
Section: Chapter 15. Kernel (Topic 1.5)

15.1 Objective 1: Manage Kernel Modules at Runtime

With Linux, code for system devices can be compiled into the kernel. Because the kernel already has built-in support for most devices, it is said to be monolithic, as the kernel manages all system hardware by itself. Monolithic kernels aren't very flexible because a new kernel build is necessary for new peripheral devices to be added to the system. Monolithic kernels also have the potential to be "bloated" by drivers for hardware that isn't physically installed. Instead, most users run modular kernels, in which device drivers are inserted into the running kernel as needed. Modular configurations can adapt to changes in the hardware and provide a convenient way of upgrading driver software while a system is running.

15.1.1 Module Files

Linux kernel modules are object files (.o) produced by the C compiler but not linked into a completed executable (in this case, the kernel executable file). Most modules are distributed with the kernel and compiled along with it. Because they are so closely related to the kernel, separate sets of modules are installed when multiple kernels are installed. This reduces the likelihood that a kernel module will be inserted into the wrong kernel version.

Modules are stored in a directory hierarchy headed by /lib/modules/kernel-version, where kernel-version is the string reported by uname -r, such as 2.2.5-15smp. In this example, the modules directory would be /lib/modules/2.2.5-15smp. Multiple module hierarchies may be available under /lib/modules if multiple kernels are installed.

Subdirectories that contain modules of a particular type exist beneath the /lib/modules/kernel-version directory. For example, for kernel 2.2.5-15smp, network interface modules are stored in subdirectory /lib/modules/2.2.5-15smp/net. This grouping is convenient for administrators but also facilitates important functionality to the modprobe command. Typical module subdirectories are:

block: Modules for a few block-specific devices such as RAID controllers or IDE tape drives.

cdrom: Device driver modules for nonstandard CD-ROM devices.

fs: Contains drivers for filesystems such as MS-DOS (the msdos.o module).

ipv4: Includes modular kernel features having to do with IP processing, such as IP masquerading.

misc: Anything that doesn't fit into one of the other subdirectories ends up here. Note that no modules are stored at the top of this tree.

net: Network interface driver modules.

scsi: Contains driver modules for the SCSI controller.

video: Special driver modules for video adapters.

Module directories are also referred to as tags in the context of module manipulation commands.

15.1.2 Manipulating Modules

A module is dynamically linked into the running kernel when it is loaded. Much of Linux kernel module handling is done automatically. However, there may be times when it is necessary for you to manipulate the modules yourself, and you may come across the manipulation commands in scripts. For example, if you're having difficulty with a particular driver, you may need to get the source code for a newer version of the driver, compile it, and insert the new module in the running kernel. The commands listed in this section can be used to list, insert, remove, and query modules.

lsmod

Syntax

lsmod

Description

For each kernel module loaded, display its name, size, use count, and a list of other referring modules. This command yields the same information as is available in /proc/modules.

Example

Here, lsmod shows that quite a few kernel modules are loaded, including filesystem (vfat, fat), networking (3c59x), and sound (soundcore, mpu401, etc.) modules, among others:

# lsmod
Module             Size  Used by
vmnet              9688   2
vmppuser           5020   0  (unused)
parport_pc         5044   0  [vmppuser]
parport            7712   0  [vmppuser parport_pc]
vmmon             14100   1
nls_iso8859-1      2020   1  (autoclean)
nls_cp437          3548   1  (autoclean)
ide-floppy         8396   1  (autoclean)
vfat              11612   1  (autoclean)
fat               25856   1  (autoclean) [vfat]
nfsd             151192   8  (autoclean)
lockd             31336   1  (autoclean) [nfsd]
sunrpc            53572   1  (autoclean) [nfsd lockd]
3c59x             18984   1  (autoclean)
opl3              11208   0  (unused)
opl3sa2            3720   0
ad1848            15984   0  [opl3sa2]
mpu401            18576   0  [opl3sa2]
sound             59064   0  [opl3 opl3sa2 ad1848 mpu401]
soundlow            304   0  [sound]
soundcore          2788   7  [sound]
aic7xxx          107024   8

insmod

Syntax

insmod [options] module

Description

Insert a module into the running kernel. The module is located automatically and inserted. You must be logged in as the superuser to insert modules.

Frequently used options

-s: Display results on syslog instead of the terminal.

-v: Set verbose mode.

Example

The msdos filesystem module is installed into the running kernel. In this example, the kernel was compiled with modular support for the msdos filesystem type, a typical configuration for a Linux distribution for i386 hardware. To verify that you have this module, check for the existence of /lib/modules/kernel-version/fs/msdos.o :

# insmod msdos
/lib/modules/2.2.5-15smp/fs/msdos.o: unresolved symbol fat_add_cluster_Rsmp_eb84f594
/lib/modules/2.2.5-15smp/fs/msdos.o: unresolved symbol fat_cache_inval_inode_Rsmp_6da1654e
/lib/modules/2.2.5-15smp/fs/msdos.o: unresolved symbol fat_scan_Rsmp_d61c58c7
  ( ... additional errors omitted ... )
/lib/modules/2.2.5-15smp/fs/msdos.o: unresolved symbol fat_date_unix2dos_Rsmp_83fb36a1
# echo $?
1

This insmod msdos command yields a series of unresolved symbol messages and an exit status of 1. This is the same sort of message that might be seen when attempting to link a program that referenced variables or functions unavailable to the linker. In the context of a module insertion, such messages indicate that the functions are not available in the kernel. From the names of the missing symbols, you can see that the fat module is required to support the msdos module, so it is inserted first:

# insmod fat

Now the msdos module can be loaded:

# insmod msdos

Use the modprobe command to automatically determine these dependencies and install prerequisite modules first.

rmmod

Syntax

rmmod [options] modules

Description

Unless a module is in use or referred to by another module, the rmmod command is used to remove modules from the running kernel. You must be logged in as the superuser to remove modules.

Frequently used options

-a: Remove all unused modules.

-s: Display results on syslog instead of the terminal.

Example

Starting with both the fat and msdos modules loaded, remove the fat module (which is used by the msdos module):

# lsmod
Module                  Size  Used by
msdos                   8348   0  (unused)
fat                    25856   0  [msdos]
# rmmod fat
rmmod: fat is in use

In this example, the lsmod command fails because the msdos module is dependent on the fat module. So, in order to unload the fat module, the msdos module must be unloaded first:

# rmmod msdos
# rmmod fat

The modprobe -r command can be used to automatically determine these dependencies and remove modules and their prerequisites.

modinfo

Syntax

modinfo [options] module_object_file

Description

Display information about a module from its module_object_ file. Some modules contain no information at all, some have a short one-line description, and others have a fairly descriptive message.

Options

-a: Display the module's author.

-d: Display the module's description.

-p: Display the typed parameters that a module may support.

Examples

In these examples, modinfo is run using modules compiled for a multiprocessing (smp) kernel Version 2.2.5. Your kernel version, and thus the directory hierarchy containing modules, will be different.

# modinfo -d /lib/modules/2.2.5-15smp/misc/zftape.o
zftape for ftape v3.04d 25/11/97 - VFS interface for the 
       Linux floppy tape driver. Support for QIC-113 
       compatible volume table and builtin compression 
       (lzrw3 algorithm)

# modinfo -a /lib/modules/2.2.5-15smp/misc/zftape.o
(c) 1996, 1997 Claus-Justus Heine 
       ([email protected])

# modinfo -p /lib/modules/2.2.5-15smp/misc/ftape.o
ft_fdc_base int, description "Base address of FDC 
       controller."
Ft_fdc_irq int, description "IRQ (interrupt channel) 
       to use."
ft_fdc_dma int, description "DMA channel to use."
ft_fdc_threshold int, description "Threshold of the FDC 
       Fifo."
Ft_fdc_rate_limit int, description "Maximal data rate 
       for FDC."
ft_probe_fc10 int, description "If non-zero, probe for a 
       Colorado FC-10/FC-20 controller."
ft_mach2 int, description "If non-zero, probe for a 
       Mountain MACH-2 controller."
ft_tracing int, description "Amount of debugging output, 
       0 <= tracing <= 8, default 3."

modprobe

Syntax

modprobe [options] module [symbol=value ...]

Description

Like insmod, modprobe is used to insert modules.^[1] However, modprobe has the ability to load single modules, modules and their prerequisites, or all modules stored in a specific directory. The modprobe command can also remove modules when combined with the -r option.

^[1] In fact, modprobe is a wrapper around insmod and provides additional functionality.

A module is inserted with optional symbol=value parameters (see more on parameters in the discussion on the module configuration file, later in this section). If the module is dependent upon other modules, they will be loaded first. The modprobe command determines prerequisite relationships between modules by reading modules.dep at the top of the module directory hierarchy (i.e., /lib/modules/2.2.5-15smp/modules.dep).

You must be logged in as the superuser to insert modules.

Frequently used options

-a: Load all modules. When used with the -t tag, "all" is restricted to modules in the tag directory. This action probes hardware by successive module-insertion attempts for a single type of hardware, such as a network adapter (in which case the tag would be net, representing /lib/modules/kernel-version/net). This may be necessary, for example, to probe for more than one kind of network interface.

-c: Display a complete module configuration, including defaults and directives found in /etc/modules.conf (or /etc/conf.modules, depending on your distribution). The -c option is not used with any other options.

-l: List modules. When used with the -t tag, list only modules in directory tag. For example, if tag is net, then modules in /lib/modules/kernel-version/net are displayed.

-r: Remove module, similar to rmmod. Multiple modules may be specified.

-s: Display results on syslog instead of the terminal.

-t tag: Attempt to load multiple modules found in the directory tag until a module succeeds or all modules in tag are exhausted. This action "probes" hardware by successive module-insertion attempts for a single type of hardware, such as a network adapter (in which case tag would be net, representing /lib/modules/kernel-version/net).

-v: Set verbose mode.

Example 1

Install the msdos filesystem module into the running kernel:

# modprobe msdos

Module msdos and its dependency, fat, will be loaded. modprobe determines that fat is needed by msdos when it looks through modules.dep. You can see the dependency listing using grep:

# grep /msdos.o: /lib/modules/2.2.5-15smp/modules.dep 
/lib/modules/2.2.5-15smp/fs/msdos.o: 
       /lib/modules/2.2.5-15smp/fs/fat.o

Example 2

Remove fat and msdos modules from the running kernel, assuming msdos is not in use:

# modprobe -r fat msdos

Example 3

Attempt to load available network modules until one succeeds:

# modprobe -t net

Example 4

Attempt to load all available network modules:

# modprobe -at net

Example 5

List all modules available for use:

# modprobe -l
/lib/modules/2.2.5-15smp/fs/vfat.o
/lib/modules/2.2.5-15smp/fs/umsdos.o
/lib/modules/2.2.5-15smp/fs/ufs.o
( ... listing continues ... )

Example 6

List all modules in the net directory for 3Com network interfaces:

# modprobe -lt net | grep 3c
/lib/modules/2.2.5-15smp/net/3c59x.o
/lib/modules/2.2.5-15smp/net/3c515.o
/lib/modules/2.2.5-15smp/net/3c509.o
/lib/modules/2.2.5-15smp/net/3c507.o
/lib/modules/2.2.5-15smp/net/3c505.o
/lib/modules/2.2.5-15smp/net/3c503.o
/lib/modules/2.2.5-15smp/net/3c501.o

On the Exam

Familiarize yourself with modules on a nonproduction Linux system, and explore the /lib/modules hierarchy. Review the modules.dep file. Be aware of what a module is, how and why it is inserted, what it means to "probe" with multiple modules, and how to determine if a module is dependent on other modules. Pay special attention to modprobe.

15.1.3 Configuring Modules

You may sometimes need to control elements of a module such as hardware interrupt assignments or Direct Memory Access (DMA) channel selections. Other situations may dictate special procedures to prepare for, or clean up after, a module insertion or removal. This type of special control of modules is implemented in the configuration file /etc/conf.modules (or in /etc/modules.conf, depending on your distribution), which controls the behavior of modprobe. The /etc/conf.modules file can contain the following information:

Comments: Blank lines and lines beginning with # are ignored.

keep: The keep parameter, when found before any path directives, causes the default paths to be retained and added to any paths specified.

depfile=full_path: This directive overrides the default location for the modules dependency file, modules.dep (described in the next section). For example:

depfile=/lib/modules/2.2.14/modules.dep

path=path_directory: This directive specifies a directory to search for modules.

options module opt1=val1 opt2=val2 ...: Options for modules can be specified using the options configuration line in conf.modules or on the modprobe command line. The command line overrides configurations in the file. module is the name of a single module without the .so extension. Options are specified as name=value pairs, where the name is understood by the module and reported using modinfo -p. For example:

options opl3 io=0x388

alias: Aliases can be used to associate a generic name with a specific module. For example:

alias scsi_hostadapter aic7xxx
alias eth0 3c59x
alias parport_lowlevel parport_pc

pre-install module command: This directive causes some shell command to be executed prior to insertion of module. For example, PCMCIA services need to be started prior to installing the pcmcia_core module:

pre-install pcmcia_core /etc/rc.d/init.d/pcmcia start

install module command: This directive allows a specific shell command to override the default module-insertion command.

post-install module: This directive causes some shell command to be executed after insertion of module.

pre-remove module: This directive causes some shell command to be executed prior to removal of module.

remove module: This directive allows a specific shell command to override the default module-removal command.

post-remove module: This directive causes some shell command to be executed after removal of module.

The following is an example the /etc/conf.modules file:

alias scsi_hostadapter aic7xxx
alias eth0 3c59x
alias parport_lowlevel parport_pc
pre-install pcmcia_core /etc/rc.d/init.d/pcmcia start
alias sound opl3sa2
pre-install sound insmod sound dmabuf=1
alias midi opl3
options opl3 io=0x388
options opl3sa2 mss_io=0x530 irq=5 dma=0 dma2=1 
       mpu_io=0x388 io=0x370

On the Exam

Remember that the files conf.modules and modules.conf are the same file, depending on distribution. Also, while it is important for you to understand the configuration lines /etc/conf.modules, detailed module configuration is beyond the scope of the LPIC Level 1 exams.

15.1.4 Module Dependency File

modprobe can determine module dependencies and install prerequisite modules automatically. To do this, modprobe scans the first column of /lib/modules/kernel-version/modules.dep to find the module it is to install. Lines in modules.dep are in the following form:

module_name.o: dependency1 dependency2 ...

A typical dependency looks like this:

/lib/modules/2.2.5-15smp/fs/msdos.o: 
       /lib/modules/2.2.5-15smp/fs/fat.o

Here, the msdos module is dependent upon fat.

All of the modules available on the system are listed in the modules.dep file and are referred to with their full path and filenames, including their .o extension. Those that are not dependent on other modules are listed, but without dependencies. Dependencies that are listed are inserted into the kernel by modprobe first, and when all of them are successfully inserted, the subject module itself can be loaded.

The modules.dep file must be kept current to ensure the correct operation of modprobe. If module dependencies were to change without a corresponding modification to modules.dep, then modprobe may fail, because a dependency could be missed. As a result, modules.dep is created each time the system is booted. On most distributions, the depmod -a command is called during rc.sysinit:

echo "Finding module dependencies" 
/sbin/depmod -a

The depmod -a command recreates and overwrites modules.dep each time the system is booted. This procedure is also necessary after any change in module dependencies. (The depmod command is actually a link to the same executable as modprobe. The functionality of the command differs depending on which name is used to call it.) The depmod command is not specifically called out in the LPIC Level 1 Objectives, but it is important to understand how the command works since it generates modules.dep.

On the Exam

Be sure you know what is in modules.dep, as well as what the file is used for, how it is created, and when it is created. Be prepared to cite the consequences of a missing or obsolete modules.dep file.