Using Linux:Managing the Kernel






-->















Previous
Table of Contents
Next




Listing Modules
Listing modules is fairly easy; you simply issue the following command:



/sbin/lsmod


Output of the program on my system looks like this:



[root@jansmachine jwalter]# /sbin/lsmod
Module Pages Used by
ppa 1 1 (autoclean)
sd_mod 4 1 (autoclean)
scsi_mod 7 [ppa sd_mod] 2 (autoclean)
vfat 3 1 (autoclean)
fat 6 [vfat]1 (autoclean)
ne 2 1 (autoclean)
8390 2 ≠ 0 (autoclean)
sound 19 0


The entries followed by (autoclean) are modules managed by kerneld. Note that the sound module is not followed by this designation, even though it is listed in the /etc/conf.modules file. This is because the module is actually loaded from an init script when the system boots.
Creating Module Dependencies
In many cases, loadable modules depend on one another to work—for example, the SCSI CD-ROM driver requires that a SCSI adapter driver be loaded before the CD-ROM driver is loaded, so it can actually access the CD device. This is a critical function of the system, and the system must keep detailed information on which module requires another module to be loaded first. There is another advantage to having interdependent modules in a system—common functionality can be built into one module, and provide this functionality to other, more specific modules. Both the SCSI and sound module systems work this way, as do some file system driver modules. For instance, the Windows 95 long-filename system, vfat, is essentially a modified version of the standard DOS filesystem. Thus it makes sense for the vfat module to use the functionality found in the msdos file system module for most of it functions. The benefit here is that the new module can take advantage of extremely well-tested, dependable code, and if a standard (non-vfat) msdos file system is mounted, there is no code being loaded twice.
The system automatically creates the module dependencies at boot-time. Under certain circumstances, it is convenient, or even necessary, to update the dependency information. It is usually done when installing modules that are not part of the standard kernel distribution, such as the latest versions of ftape, the module that provides access to QIC tape drives. You also want to run module dependencies if you have changed your modules.conf to include additional directories where modules are kept. This prevents surprises if there are errors or problems with the modules in the directories that have been added and the system is rebooted, since you’ll see any error messages while the system is still in a state at which these problems can be fixed.
To have the system generate new module dependencies, log on as root and issue the following command:


/sbin/depmod -a


The system searches the standard module directory trees and generates dependencies for every module it finds.

If you want to keep certain modules in directories outside the standard module directory tree (/lib/modules/<kernel-version>, where <kernel-version> is the current version of the Linux kernel), you must add the following to the top of your modules.conf file and restart kerneld:


keep
path=<path name>


Again, <path name> points to the directory where the additional modules are kept. The keep directive tells the module utilities to append the directory name to the module paths. If this directory is not there, the module path will be replaced, which most likely is not what you want.
Enabling Modules at Boot Time
The module management utilities can be configured to load entire directories of modules at boot time. This is not the same as using initrd to get the kernel to pre-load modules.
This process is a viable alternative to listing individual modules to be loaded at boot time in init scripts, or to letting kerneld automatically load and unload them.


In case you forget…
The kernel must be able to read the hard disk to load modules at boot time, which means that this is not the place to put entries for the SCSI adapter drivers that your system boots from because by the time the kernel has booted, the drivers must already be loaded and initialized for Linux to read the hard disk. These SCSI drivers that allow your system to boot are loaded from the initial ramdisk.

Loading a module at boot time by using modules.conf

1.  Create a directory in which these modules should be kept. Use something like /lib/modules/<kernel version>/boot to keep the modules with the kernel version they were compiled for, and also within the directory tree where the rest of the world expects to see modules.
2.  Copy the modules you need to load at boot time to the directory.
3.  Make sure the first line of /etc/conf.modules is the directive keep. You don’t want your module utilities thinking that this is the only thing you want them to do.
4.  Add the line path[boot]=/lib/modules/’uname -r’/boot as the next line of /etc/conf.modules. If you want to make sure that you have typed this correctly before saving your changes, execute the command echo /lib/modules/’uname -r’/boot on another virtual terminal or xterm. The output should have your current kernel version in place of the ‘uname -r’.
5.  Restart kerneld. There are lots of ways to do this, but the command /etc/rc.d/init.d/kerneld restart works adequately.





Previous
Table of Contents
Next