"Linux Gazette...making Linux just a little more fun!"

Kernel modules provided support for a lot of functions within Linux. Unfortunately, I wasn't able to find a simple explanation of what they are and how to use them when I needed it.

Last summer, I installed Red Hat Linux 5.1 on my ThinkPad 770 portable computer. I used to be a Unix System Administrator and had installed Red Hat 4.1 on a computer a few years ago, so I expected to be able to solve any problems I encountered during the installation. The initial installation went smoothly.

I was taken aback to discover that I couldn't set up dialup network services. The configuration files were all there, but the system didn't seem to have kernel support for networking. I couldn't find any explanation in the documentation I had, but after digging around in Deja News (https://www.dejanews.com/), I learnt that kernel modules provided network support.

As operating systems evolve and grow over time, the designers of the system face a dilemma. If support for all possible functionality is included within the operating system kernel, the core program that controls the system, the kernel becomes very large and unwieldy. If support for the functionality is not included in the kernel, the functions will either work too slowly or won't work at all. Operating system designers typically solve this dilemma by modularizing support for functionality that can then be included or left out.

Traditionally, there are two ways to provide this modularity. The designer can separate functionality into separate processes called threads or the kernel can be recompiled to include/exclude any functions (not) included by the vendor. If the functionality is separated into threads, the kernel is called a micro-kernel. This solution imposes communications overhead as the threads coordinate their work. A kernel that has all of its functionality included when it is built is called a monolithic kernel. As the name implies, the downside of this solution is the size of the kernel. Linux' solution was to include kernel modules which can be loaded and unloaded on demand. This minimizes both kernel size and communication overhead.

Kernel modules have always been in Linux, as far as I can determine. The number of modules available and the mechanisms to support and operate them have evolved along with the operating system.

Originally they were supplied with the modprobe/depmod and insmod/lsmod/rmmod/ksyms utilities for managing them. These utilities are described in the usual cryptic manner in the man pages. With the introduction of Linux 1.3, the daemon 'kerneld' was added to Linux to manage kernel modules automatically. The kerneld mini-HOWTO (ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/) describes this daemon and its use very thoroughly.

Modules should be used to support functionality that is only used part of the time. For example, if you don't need network support all of the time, the normal case if you only have dial-up networking, loadable modules should provide networking support.

The required modules can be loaded just prior to calling your Internet service provider (ISP). When you disconnect, the modules can be unloaded. This minimizes the amount of memory required by the kernel and speeds up operation.

Of course, functionality that is required all the time, such as access to your main hard disk must be built into the kernel. If you are building a network workstation or a web server, both of which require constant network access, you should consider building the network functionality into the kernel. An alternative approach would be to load the network modules during startup. The advantage to this approach is that you don't need to rebuild your kernel. The disadvantage is that the network functions won't be as efficient.

One of the main advantages of Linux over commercial operating systems is that it comes with complete source code. You can rebuild or modify any part of the system. However, this advantage assumes that you are a computer programmer. You need to understand things like 'make' and 'c'. If you're a computer user, and given the speed of change in this industry that's the category I fit in, then trying to rebuild the Linux kernel can be a daunting undertaking. Furthermore, if you make a mistake rebuilding the kernel you will probably have to start your installation over from scratch. Personally, I'm willing to attempt to rebuild the kernel only after exhausting every other possible solution.

As Mike Borowiec, in a recent letter to the editor of Performance Computing, said, " This is not something I'd want mom to do."

However, that said, rebuilding the kernel is very straightforward. The Linux Kernel HOWTO (ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/) gives detailed instructions. Without going into detail, the steps are as follows: Load all the source files onto your working system Decide what functions you want included in the kernel Use 'make config' to select those options Use 'make' to actually rebuild the kernel Install the new kernel Tell your startup routine, normally Lilo, to use your new kernel Reboot your computer

To load modules at startup, the load commands must be included in the correct startup script. The system startup scripts for Linux are not part of any official Linux package. Each distributor, Red Hat, Slackware, Debian, etc. creates its own scripts. Thus, it is impossible to give specific instructions that can be used by everyone. The reader is going to have to determine what system startup scripts are used in his/her distribution. As a starting point, look for a file or directory called 'rc*.d', where * means 'anything could go here'. Then use grep to look for 'depmod -a' and/or 'insmod'. The Linux Modules Installation mini-HOWTO (ftp://metalab.unc.edu/pub/Linux/docs/linux-doc-project/) gives more details.

I must point out that you should never make changes to these startup scripts without first saving the current version. That way you will be able to get back to your starting point if you make a mistake.

The Linux Modules Installation mini-HOWTO recommends creating a file called '/etc/rc.d/init.d/modules.init' to contain the commands if you have a Red Hat or Debian version of Linux. However, my version of Red Hat has the 'depmod -a' command in '/etc/rc.d/rc.sysinit'. You will probably find at least one line that contains the modprobe or insmod command. Add commands for any new modules you want loaded at startup at this point in the file.

After rebooting your computer, use the lsmod command to check that the modules are actually running.

Starting with the 1.3.57 version of Linux, a daemon called 'kerneld' was added to the system. This daemon's job is to automatically load and unload modules upon demand from the kernel. One of the advantages of this is that distributors only have to distribute one version of the kernel. The daemon will load all of the required functionality for the specific system as needed. If your system startup script contains the line '/sbin/kerneld', then your system has been configured to use the daemon.

Most likely, all of the modules you need will run correctly without additional configuration. If you do need to change the configuration, the kerneld mini-HOWTO (ftp://metalab.unc.edu/pub/Linux/docs/linux-doc-project/) describes the configuration files and how to modify them in great detail.

Sometimes, you will want to have explicit control over when and how modules are loaded. First, you need to make sure that your module won't load automatically by modifying the configuration files so that kerneld doesn't know about the module. Then you will have to create scripts to startup and shut down the functionality.

The 'depmod -a' command in the system startup script creates a dependency list for all the modules available to the system. This is necessary as some modules assume other modules are already loaded. The 'modprobe module-name' command uses this dependency list to load any required modules before loading the requested module. It will generate an error message if 'module-name' can't be found in the dependency list. Alternatively, the insmod command can be used to load a module if you know that all dependent modules have already been loaded.

An example of when this might be needed is dial-up networking. There are a number of scripts for properly starting dial-up networking. You need to modify the startup script by adding the modprobe or insmod command to load networking functionality. I recommend using lsmod and grep to check that the modules aren't' already loaded. You also need to modify the scripts for properly stopping dial-up networking by adding the rmmod command to unload the network functionality. For details regarding the scripts related to dial-up networking, read the PPP mini-HOWTO (ftp://metalab.unc.edu/pub/Linux/docs/linux-doc-project/)

Most of the information that I've gathered here about modules came from the Linux Documentation Project. To quote from the project homepage (https://metalab.unc.edu/mdw/ldp.html):

"The Linux Documentation Project (LDP) is working on developing good, reliable documentation for the Linux operating system. The overall goal of the LDP is to collaborate in taking care of all of the issues of Linux documentation, ranging from online documentation (man pages, HTML, and so on) to printed manuals covering topics such as installing, using, and running Linux."

All of the documentation developed by the project is available online at ftp://sunsite.unc.edu/pub/Linux/docs/. The manuals that I used were: The Linux Users' Guide, The Linux Kernel HOWTO, The Linux Modules Installation mini- HOWTO and The kerneld mini- HOWTO. The document with the best debugging information was the Linux PCMCIA HOWTO. Additional information came from the Linux PPP HOWTO and the Linux IPX HOWTO.

Another excellent source of information is the Linux news archives at Deja-News. This is a repository of all of the information that has been posted on the Internet news groups. It provides full text searching capabilities and allows you to post new information or questions. Since there is so much information stored at the site it takes patience and tenacity to find the answers you need. Persevere, as the information you need is usually buried in the repository.

The reader may being asking by now, "If your Red Hat 5.1 distribution contained kerneld, why were you experiencing problems?" A fair question, the answer being that I was too smart for my own good. Whoever wrote the Red Hat system startup script knew that Lilo, the startup routine, has an option labeled 'linux' that contains the name of the kernel. The startup script needed the kernel name to determine which version of modules to install.

During installation, I told Lilo to change the name of this option to 'l'. My reason was partly that I'm lazy and partly that Lilo doesn't give you much time to enter a boot option. I have two operating systems on the same computer. When Lilo starts, it gives me 10 seconds to enter an option label. It is much quicker to type 'l'.

This clever modification defeated the equally clever method used by the system startup script author. As a result, the system would not install kerneld. Without kerneld, my system did not have the required network modules. I'm sure there's a lesson in the experience somewhere.