Kernel Components (2.201.1)

Kernel Components (2.201.1)
Prev	Chapter 1. Linux Kernel (2.201)	Next

Candidates should be able to utilise kernel components that are necessary to specific hardware, hardware drivers, system resources and requirements. This objective includes implementing different types of kernel images, identifying stable and development kernels and patches, as well as using kernel modules.

Key files, terms and utilities include:

/usr/src/linux

/usr/src/linux/Documentation

zImage

bzImage

Key knowledge area:

Kernel documentation (2.4 and 2.6)

Different types of kernel images

A kernel can be monolithic or not. A monolithic kernel is a kernel that contains all the driver code needed to use all the hardware connected to or contained within the system you are configuring. Such a kernel does not need the assistance of modules. So why doesn't everyone just build a monolithic kernel and be done with it? The main reason is that such kernels tend to be rather large and often won't fit on a single floppy disk. Another reason is that the implementation of a new improved driver for a certain piece of hardware immediately results in the need for a new kernel. This is not the case with modules as will be explained in the section called “Using kernel modules”.

Most of the time, a kernel image is compressed to save space. There are two types of compressed kerneltypes: zImage and bzImage

The difference between “zImage” and “bzImage” files lies in their different layout and loading algorithms. For zImage the allowed kernelsize is 520Kb (see: Johnson01), bzImage doesn't have this restriction. As a result the bzImage kernel now is the preferred image type.

Note

Both images use gzip compression. The “bz” in “bzImage” stands for “big zImage”, not for “bzip”!

Identifying stable and development kernels and patches

A kernel version number consists of three parts: major, minor and the patch level, all separated by periods.

The major release is incremented when a major change in the kernel is made.

The minor release is incremented when significant changes and additions are made. Even-numbered minor releases, e.g. 2.4, 2.6, 2.8, are considered stable releases and odd-numbered releases, e.g. 2.1, 2.3 are considered to be in development and are primarily used by kernel developers.

The last part of the kernel version number is the so-called patch level. As errors in the code are corrected (and/or features are added) the patch level is incremented. You should only upgrade your kernel to a higher patch level when your current kernel has a security problem or doesn't function properly or when new functionality has been added to the kernel.

Using kernel modules

Linux kernel modules are object files (.o for 2.4 kernels and .ko for 2.6 kernels) produced by the C compiler but not linked into a complete executable. Kernel modules can be loaded into the kernel to add functionality when needed. Most modules are distributed with the kernel and compiled along with it. Every kernel version has its own set of modules.

Modules are stored in a directory hierarchy under /lib/modules/kernel-version, where kernel-version is the string reported by uname -r, such as 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. This grouping is convenient for administrators, but also facilitates important functionality to the command modprobe.

Typical module types:

block: Modules for a few block-specific devices such as RAID controllers or IDE tape drives.
cdrom: Device driver modules for nonstandard CD-ROM drives.
fs: 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.

Manipulating modules

lsmod

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. On a particular laptop, for instance, the command /sbin/lsmod reports:

Module                  Size  Used by
serial_cb               1120   1
tulip_cb               31968   2
cb_enabler              2512   4 [serial_cb tulip_cb]
ds                      6384   2 [cb_enabler]
i82365                 22384   2
pcmcia_core            50080   0 [cb_enabler ds i82365]

The format is name, size, use count, list of referring modules. If the module controls its own unloading via a “can_unload” routine, then the user count displayed by lsmod is always -1, irrespective of the real use count.

insmod

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

Frequently used options:

-s: Write results to syslog instead of the terminal.
-v: Set verbose mode.

Example 1.1. Example

The kernel was compiled with modular support for a specific sound card. To verify that this specific module, in this case maestro3.o exists, look for the file maestro3.o in the /lib/modules/kernel-version directory:

# insmod maestro3
Using /lib/modules/2.4.9/kernel/drivers/sound/maestro3.o
/lib/modules/2.4.9/kernel/drivers/sound/maestro3.o: \
    unresolved symbol ac97_probe_codec_R84601c2b
# echo $?
1

This insmod maestro3 command yields an unresolved symbol 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 name of the missing symbol, you can see that the ac97_codec module is required to support the maestro3 module, so it is inserted first:

# insmod ac97_codec
Using /lib/modules/2.4.9/kernel/drivers/sound/ac97_codec.o
# insmod maestro3
Using /lib/modules/2.4.9/kernel/drivers/sound/maestro3.o
# lsmod
Module                  Size  Used by
maestro3               24272   0  (unused)
ac97_codec              8896   0  [maestro3]
serial_cb               1456   1 
tulip_cb               32160   2 
cb_enabler              2752   4  [serial_cb tulip_cb]
ds                      6864   2  [cb_enabler]
i82365                 22512   2 
pcmcia_core            49024   0  [cb_enabler ds i82365]

As the output from the lsmod command above shows, the two modules maestro3 and ac97_codec have both been loaded.

rmmod

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

Example 1.2. Example

# rmmod ac97_codec
ac97_codec: Device or resource busy
# echo $?
1

The module can't be unloaded because it is in use, in this case by the maestro3 module. The solution is to remove the maestro3 module first:

# rmmod maestro3
# rmmod ac97_codec
# echo $?
0

Issue the command lsmod to verify that the modules have indeed been removed from the running kernel.

modprobe

Like insmod, modprobe is used to insert modules. 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.

A module is inserted with optional symbol=value parameters such as irq=5 or dma=3 . This can be done on the command line or by specifying options in the module configuration file as will be explained later on. 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, for instance /lib/modules/2.4.9/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. 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 version of module utilities. Note that the LPIC objective requires you to know both names). 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.
-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.
-v: Set verbose mode.

Example 1.3. Example

Loading sound modules using modprobe.

# modprobe maestro3
# echo $?
0
# lsmod
Module                  Size  Used by
maestro3               24272   0  (unused)
ac97_codec              8896   0  [maestro3]
serial_cb               1456   1 
tulip_cb               32160   2 
cb_enabler              2752   4  [serial_cb tulip_cb]
ds                      6864   2  [cb_enabler]
i82365                 22512   2 
pcmcia_core            49024   0  [cb_enabler ds i82365]

Both the modules have been loaded. To remove both the modules, use modprobe -r maestro3.

modinfo

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

Options from the man-page:

-a, --author: Display the module's author.
-d, --description: Display the module's description.
-n, --filename: Display the module's filename.
-fformat_string, --format format_string: Let's the user specify an arbitrary format string which can extract values from the ELF section in module_file which contains the module information. Replacements consist of a percent sign followed by a tag name in curly braces. A tag name of %{filename} is always supported, even if the module has no modinfo section.
-p, --parameters: Display the typed parameters that a module may support.
-h, --help: Display a small usage screen.
-V, --version: Display the version of modinfo.

Example 1.4. Example

What information can be retrieved from the maestro3 module:

pug:~# modinfo maestro3
filename:    /lib/modules/2.4.9/kernel/drivers/sound/maestro3.o
description: "ESS Maestro3/Allegro Driver"
author:      "Zach Brown <zab@zabbo.net>"
parm:        debug int
parm:        external_amp int

Configuring modules

You may sometimes need to control the assignments of the resources a module uses, such as hardware interrupts or Direct Memory Access (DMA) channels. Other situations may dictate special procedures to prepare for, or clean up after, module insertion or removal. This type of special control of modules is configured in the file /etc/modules.conf.

Commonly used directives in /etc/modules.conf:

keep

The keep directive, 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 which will be described in the next section.

path=path

This directive specifies an additional directory to search for modules.

options modulename module-specific-options

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

alias aliasname result

Aliases can be used to associate a generic name with a specific module, for example:

alias /dev/ppp          ppp_generic
alias char-major-108    ppp_generic
alias tty-ldisc-3       ppp_async
alias tty-ldisc-14      ppp_synctty
alias ppp-compress-21   bsd_comp
alias ppp-compress-24   ppp_deflate
alias ppp-compress-26   ppp_deflate

pre-install module command

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

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

install module command

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

post-install module command

This directive causes a specified shell command to be executed after insertion of the module.

pre-remove module command

This directive causes a specified shell command to be executed prior to removal of module.

remove module command

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

post-remove module command

This directive causes a specified shell command to be executed after removal of module.

For more detailed information concerning the module-configuration file see man modules.conf.

Blank lines and lines beginning with a # are ignored in modules.conf.

Module Dependency File

The command 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 ...

example for ac97_codec and maestro3:

/lib/modules/2.4.9/kernel/drivers/sound/ac97_codec.o:

/lib/modules/2.4.9/kernel/drivers/sound/maestro3.o: \
    /lib/modules/2.4.9/kernel/drivers/sound/ac97_codec.o

Here the ac97_codec module depends on no other modules and the maestro3 module depends on the ac97_codec module.

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 after they have been 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 would fail because a dependency would be missed. As a result, modules.dep needs to be (re)created each time the system is booted. Most distributions will do this by executing depmod -a automatically when the system is booted.

This procedure is also necessary after any change in module dependencies.