Kernel, Cron, and User Administration, Part 1 - Understanding Kernel Modules
(Page 10 of 11 )
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.
EXAM WATCH! If you’re having problems with hardware related kernel modules, one utility you can try is kudzu, the Red Hat hardware detection and configuration utility. It is normally run during the boot process, but you might try running it again if you’re having a problem. |
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.
 This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.
|
Next: /lib/modules/kernel_version/ Directory Structure >>
More Administration Articles
More By McGraw-Hill/Osborne
/ 11 
