Auto-loading Kernel Modules

Removing code from the kernel that provides unneeded support is one option long associated with Linux. Now, you can remove code that is not constantly required, putting it in modules loaded on command.

Like many operating systems, Linux offers support for numerous devices, file systems, and network protocols. Unfortunately, this growing support increases the memory requirements of the kernel. Linux partially solves this problem by allowing selection of only the features you need when compiling the kernel. This is further improved by allowing some features to be compiled as modules, so they can be loaded only when they are needed. The loading and unloading of modules can be automated with the use of kerneld, making the use of features compiled as modules just as easy as using those included in the basic kernel.

To use kerneld, you should start by installing the most recent version of the modules package, found at www.pi.se/blox/modules/. I'm using modules-1.3.69f, but there's probably a newer version out by the time you read this article. Also, you'll need a kernel at least as recent as 1.3.57.

Fortunately, kerneld automatically knows about most modules. All you must do is run it in your startup script. For Slackware-based systems, you'll need to edit /etc/rc.d/rc.local. You should include the following:

# Update kernel-module dependencies file
[ -x /sbin/depmod ] && {
        /sbin/depmod -a
}
# Start kerneld
[ -x /sbin/kerneld ] && {
        /sbin/kerneld
}

For Red Hat systems, you can install the contributed modules RPM on ftp.redhat.com in /pub/contrib/RPMS/ called modules-1.3.57-3.i386.rpm which provides support for kerneld. A newer version will probably be released by the time you read this, so look for a later version of the modules utility if you can't find it there. Alternately, read the article “Understanding Red Hat Runlevels” in LJ issue 27 (July 1996) and create a kerneld boot script in /etc/init.d with appropriate links in /etc/rc2.d, /etc/rc3.d, /etc/rc4.d, and /etc/rc5.d.

In either case, this runs depmod, which updates dependency information used by kerneld and then starts kerneld, which forks and hides in the background until the kernel needs it.

Now, all you need to do is reconfigure your kernel to use modules for the features you're not always using, and build and install the kernel and the modules. If you've never built modules before, simply add two steps to the kernel compilation process: make modules and make modules_install.

When you boot the new kernel, you should have all your modules loading automatically whenever you try to use them. The command lsmod will tell you which modules are loaded. Of course, it is a good idea to keep your old kernel bootable in case something doesn't work as expected.

Unfortunately, kerneld doesn't know about every module you might want to install—particularly those not part of the kernel distribution. To install these modules, you'll need to tell kerneld about them in /etc/conf.modules. Kerneld needs to know both where to find the module and what event triggers loading it.

I strongly recommend you use the default directories for your modules. Otherwise, you'll have to add not only the new path to /etc/conf.modules, but all the default paths as well. To see the default paths, use modprobe -c | more.

Telling kerneld what triggers the loading of a module requires adding alias entries in /etc/conf.modules. For device drivers, such as zftape.o or joystick.o, the format is based on the device type (character or block) and major number. For example, I use alias char-major-15 joystick for the joystick driver. You can get a bunch of examples by running modprobe -c to see the defaults. You can have multiple entries for the same module if there are multiple events that should trigger loading it.

You may also need to set an alias if you want to load an optional module, like BSD compression with PPP. The simplest alias to use for BSD compression is alias ppp bsd_comp. This will tell kerneld to load bsd_comp instead of ppp, but since bsd_comp requires the real ppp module (which requires slhc), it will load slhc and ppp first. Of course, if you have trouble with this, you can always load the modules explicitly in your dialing script and unload them in /etc/ppp/ip-down.

You can also use kerneld to set up a dial-on-demand network connection. When the kernel receives a request to send a packet to an IP address for which there is no routing information, it asks kerneld if it can establish a route to that address. When kerneld receives such a request, it runs /sbin/request-route, which should, generally, be a script to start PPP or SLIP, thereby establishing a route.

So, all you have to do is replace /sbin/request-route with your dialing script. Well... not exactly. If you rely completely on an outside nameserver, you can probably get away with that. In general, however, you need to be careful, as kerneld may call request-route several times, once for each IP address the kernel needs to resolve. This can be solved by using a lock file for the modem device, which is an option for chat and pppd. [You should be using that option anyway! —ED]

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState