Kernel Modules
Over the years the Linux kernel has evolved. In the past, device drivers were included as part of this core program, for example, but now they are loaded on demand as modules.
Reasons for Kernel Modules
This new architecture has a number of advantages:
Updates to a driver, such as a USB controller module, don't require a complete recompilation of the kernel; just the module itself needs recompiling. This reduces the likelihood of errors and ensures that the good, working base kernel remains unchanged. An error in a device driver is less likely to cause a fault that prevents your system from booting. A faulty device driver can be prevented from loading at boot time by commenting out its entry in the /etc/modprobe.conf file, or by using the rmmod command after boot time. In the past, the kernel would have to be recompiled. Updates to a driver don't require a reboot either, just the unloading of the old and reloading of the new module. You can add new devices to your system without requiring a new kernel, only the new module driver is needed. This adds a great deal of flexibility without a lot of systems administrator overhead.
There are some drivers that will always need to be compiled into the kernel to make sure your system boots correctly. For example, routines for basic system functions used in reading and writing files are an indispensable integrated part of any kernel.
Loadable kernel modules now include device drivers to manage various types of filesystems, network cards, and terminal devices to name a few. As they work so closely with the kernel, the modules need to be compiled specifically for the kernel they are intended to support. The kernel always looks for modules for its version number in the /lib/modules/<kernel version> directory and permanently loads them into RAM memory for faster access. Some critical modules are loaded automatically, others need to be specified in the /etc/modprobe.conf file.
The kernel recompilation process provides you with the option of compiling only the loadable modules. I won't specifically cover this, but simultaneous recompilation of all modules will be covered as part of the overall recompilation of your kernel.
How Kernel Modules Load When Booting
One question that must come to mind is "How does the kernel boot if the disk controller modules reside on a filesystem that isn't mounted yet?"
As stated in Chapter 7, "The Linux Boot Process," the GRUB boot loader resides on its own dedicated partition and uses the /boot/grub/grub.conf file to determine the valid kernels and their locations. The grub.conf file not only defines the available kernels, but also the location of the root partition and an associated ramdisk image that is automatically loaded into memory and that contains just enough modules to get the root filesystem mounted.
|
In Fedora Linux, the /boot/grub/grub.conf file can also be referenced via the symbolic link file named /etc/grub.conf.
|
Modules and the grub.conf File
In this example of the /boot/grub/grub.conf file, the kernel in the /boot directory is named vmlinuz-2.6.8-1.521, its RAM disk image file is named initrd-2.6.8-1.521.img, and the root partition is (hd0,0).
#
# File: /boot/grub/grub.conf
#
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora Core (2.6.8-1.521)
root (hd0,0)
kernel /vmlinuz-2.6.8-1.521 ro root=LABEL=/
initrd /initrd-2.6.8-1.521.img
The .img file is created as part of the kernel compilation process, but can also be created on demand with the mkinitrd command.
The (hd0,0) disk definition may seem strange, but there is a file that maps the GRUB device nomenclature to that expected by Linux in the /boot/grub/device.map file.
#
# File: /boot/grub/device.map
#
(fd0) /dev/fd0
(hd0) /dev/hda
During the next phase of the boot process, the loaded kernel executes the init program located on the RAM disk, which mounts the root filesystem and loads the remaining modules defined in the /etc/modprobe.conf file before continuing with the rest of the startup process.
Loading Kernel Modules on Demand
It is possible to load add-on modules located under the /lib/modules/<kernel version> directory with the modprobe command. For example, the iptables firewall application installs kernel modules that it uses to execute NAT and pass FTP traffic. In this example, these modules are loaded with the modprobe command with the aid of the /etc/rc.local script.
#
# File: /etc/rc.local
#
# Load iptables FTP module when required
modprobe ip_conntrack_ftp
# Load iptables NAT module when required
modprobe iptable_nat
Kernel module drivers that are referenced by the operating system by their device aliases are placed in the /etc/modprobe.conf file and are loaded automatically at boot time. In the example, you can see that devices eth1 and eth0 use the natsemi and orinoco_pci drivers respectively.
#
# /etc/modprobe.conf
#
alias eth1 natsemi
alias eth0 orinoco_pci
Linux has a number of commands to help you with modules. The lsmod command lists all the ones loaded. In the example, you can see that iptables, NFS, and the Orinoco drivers are all kernel modules. You can use the modprobe command to load and unload modules or use the insmod and rmmod commands. See the man pages for details.
[root@bigboy tmp]# lsmod
Module Size Used by
...
...
iptable_filter 2048 0
ip_tables 13440 1 iptable_filter
...
...
exportfs 4224 1 nfsd
nfs 142912 0
lockd 47944 3 nfsd,nfs
autofs4 10624 1
sunrpc 101064 20 nfsd,nfs,lockd
...
...
natsemi 18016 0
orinoco_pci 4876 0
orinoco 31500 1 orinoco_pci
hermes 6528 2 orinoco_pci,orinoco
...
...
[root@bigboy tmp]#
Finally, when in doubt about a device driver, try using the lspci command to take a look at the devices that use your PCI expansion bus. Here you can see that the natsemi module listed in the lsmod command has a high probability of belonging to the 01:08.0 Ethernet controller: device made by National Semiconductor.
[root@bigboy tmp]# lspci
...
...
01:07.0 Network controller: Intersil Corporation Prism 2.5 Wavelan
chipset (rev 01)
01:08.0 Ethernet controller: National Semiconductor Corporation
DP83815 (MacPhyter) Ethernet Controller
01:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 78)
[root@bigboy tmp]#
 | 
