Understanding Kernel Modules - Administration

When you compile your kernel, you can set up a monolithic kernel with every driver that you might ever need. Unfortunately, such kernels are large, unwieldy, and take a lot of time to load. Generally, most Linux administrators use kernel modules. As described earlier, a kernel module is not compiled directly into the kernel but instead operates as a pluggable driver that can be loaded and unloaded into the kernel as needed.

To have the kernel dynamically load and unload kernel modules as needed, the kernel module loader, kmod, is used to control the loading and unloading of modules. For special parameters and options, edit the /etc/modules.conf file.

Most hardware modules are automatically detected. If you’ve just installed new undetected hardware, you could issue the following command:

# depmod -a

This will scan through your modules, find out what the different dependencies for all your modules are, and map them out to a file (modules.dep). This command also creates a number of other files in the /lib/modules/2.4.21-4.EL/ directory (if you’ve installed another kernel, the directory version changes accordingly).

RHEL 3 runs this command automatically through the /etc/rc.sysinit script. Once the depmod module scan is complete, you can load additional kernel modules. If that module has dependencies, then all the needed modules will automatically load first.

To load a module, you can use the modprobe command with the name of a specific driver:

# modprobe 3c503

In this example, the Ethernet module for a 3Com 503 network card requires the 8390 module to work properly. If depmod was run first, then 8390 would have loaded automatically before the 3c503 driver. If a dependency in the list fails during loading, then all modules will be automatically unloaded.

Alternatively, you can set up these modules in /etc/modules.conf. It should already be configured during the RHEL 3 installation process. Unfortunately, this work can be rather tedious. The following commands are accepted in this file:

• alias  Allows you to bind a name to a module.
• options  Allows you to specify options for a module.
• install module command  Use commandinstead of insmod on this module.
• pre-install module command  Run commandbefore installing this module.
• post-install module command  Run commandafter installing this module.
• remove module command  Use commandinstead of rmmod on this module.
• pre-remove module command  Run commandbefore loading this module.
• post-remove module command  Run commandafter loading this module.

Here is an example of what a common modules.conf file may look like:

alias eth0 pcnet32
alias usb-controller usb-uhci
options sb irq=5 io=0x220 dma=1
alias midi awe_wave
alias parport_lowlevel parport_pc

Here the eth0 device is bound to the pcnet32 module. To load the network card, you can then simply type modprobe eth0 without knowing what card is in the computer. The next command sets the USB controller. The following two lines show the configuration of a soundblaster (sb) module. This information includes a specific IRQ port, I/O address, and DMA channel. The options line specifies these options and binds them to the sb alias. The sound card happens to be a Sound Blaster AWE 32 model card; therefore, the midi alias is bound to the awe_wave module. Finally, a parallel port module is bound to the parport_lowlevel alias.

The /etc/rc.sysinit script recognizes certain aliases and will load them if it finds them in this file. You need to specifically place the sound modules in modules.conf to have them automatically loaded. To have the sound modules automatically loaded during the Linux boot process without having to edit the /etc/rc.sysinit file, you can simply create an alias to sound and or midi in the modules.conf file.

To see what modules are loaded, you can type either

# cat /proc/modules

or

# lsmod

Both commands return output that looks something like the following:

Module        Size  Used by     Not tainted
nfs           92912  1 (autoclean)
ide-cd        35680  0 (autoclean)
cdrom         33696  0 (autoclean) [ide-cd]
smbfs         44528  1 (autoclean)
nfsd          85456  8 (autoclean)
lockd         59856  1 (autoclean) [nfs nfsd]
sunrpc        85692  1 (autoclean) [nfs nfsd lockd]
parport_pc    19076  1 (autoclean)
lp             9028  0 (autoclean)
parport       37088  1 (autoclean) [parport_pc lp]
autofs        13364  0 (autoclean) (unused)
pcnet32       18080  1
mii            3976  0 [pcnet32]
crc32          3712  0 [pcnet32]
ipt_REJECT     4632  1 (autoclean)
ipt_state      1080  1 (autoclean)
ip_conntrack  27304  1 (autoclean) [ipt_state]
iptable_filter 2412  1 (autoclean)
ip_tables     15776  3 [ipt_REJECT ipt_state iptable_filter]
floppy        58160  0 (autoclean)
microcode      4724  0 (autoclean)
keybdev        2976  0 (unused)
mousedev       5524  1
hid           22212  0 (unused)
input          5888  0 [keybdev mousedev hid]
usb-uhci      26412  0 (unused)
usbcore       79392  1 [hid usb-uhci]
ext3          91592  3
jbd           52336  3 [ext3]
raid1         14988  2

The module name is listed on the left, and its size is in the second column. The “Used by” column shows more detail on how the module is being handled. An autoclean message means that the kernel, using the kmod thread is taking care of the module and will handle removing it. If a module name, such as ext3, is listed in brackets, then the module depends on the module in brackets. In our example, jbd depends on the ext3 module.