Credits

This document is based on an original HTML version 1.7 dated July 19, 1997 by Henrik Storner <storner@osiris.ping.dk> and was revised and translated to DocBook DTD by Gary Lawrence Murphy <garym@teledyn.com> May 20, 2000.

The following people have contributed to this mini-HOWTO at some point:

• Bjorn Ekwall bj0rn@blox.se

• Ben Galliart bgallia@luc.edu

• Cedric Tefft cedric@earthling.net

• Brian Miller bmiller@netspace.net.au

• James C. Tsiao jtsiao@madoka.jpl.nasa.gov

If you find errors in this document, please send email to <kerneld-howto@linuxdoc.org>. Your comments, encouragement and suggestions are welcome and appreciated, and help ensure this guide remains current and accurate.

Why do I want to use it ?

There are some good reasons for using kerneld. The ones I will mention are mine, others have other reasons.

• If you have to build kernels for several systems that only differ slightly - different kind of network card, for instance - then you can build a single kernel and some modules, instead of having to build individual kernels for each system.

• Modules are easier for developers to test. You don't need to reboot the system to load and unload the driver; this applies to all modules, not just kerneld-loaded ones.

• It cuts down on the kernel memory usage leaving more memory available for applications. Memory used by the kernel is never swapped out, so if you have 100Kb worth of unused drivers compiled into your kernel, they are simply wasting RAM.

• Some of the things I use, the ftape floppy-tape driver, for instance, or iBCS, are only available as modules, but I don't want to bother with loading and unloading them whenever I need them.

• People making Linux distributions don't have to build 284 different boot images: Each user loads the drivers he needs for just his hardware. Most modern Linux distributions will detect your hardware and will only load those modules actually required.

Of course, there are also reasons why you may not want to use it. If you prefer to have just one kernel image file with all of your drivers built in, you are reading the wrong document.

Where can I pick up the necessary pieces ?

The support in the Linux kernel was introduced with Linux 1.3.57. If you have an earlier kernel version, you will need to upgrade if you want the kerneld support. The current Linux kernel sources can be found at most Linux FTP archive sites including:

• Kernel.Org Archive

• Metalab Linux Archive

• TSX-11 at MIT

The user-space daemon is included with the modules package. These are normally available from the same place as the kernel sources

Trying out kerneld

Now reboot with the new kernel. When the system comes back up, you can run ps ax, and you should see a line for kerneld:

    PID TTY STAT  TIME COMMAND
     59  ?  S     0:01 /sbin/kerneld

One of the nice things with kerneld is that once you have the kernel and the daemon installed, very little setup is needed. For a start, try using one of the drivers that you built as a module; it is more likely than not that it will work without further configuration. If I build the floppy driver as a module, I could put a DOS floppy in the drive and type

  osiris:~ $ mdir a:
   Volume in drive A has no label
   Volume Serial Number is 2E2B-1102
   Directory for A:/

  binuti~1 gz       1942 02-14-1996  11:35a binutils-2.6.0.6-2.6.0.7.diff.gz
  libc-5~1 gz      24747 02-14-1996  11:35a libc-5.3.4-5.3.5.diff.gz
          2 file(s)        26689 bytes

The floppy driver works! It gets loaded automatically by kerneld when I try to use the floppy disk.

To see that the floppy module is indeed loaded, you can run /sbin/lsmod to list all currently loaded modules:

  osiris:~ $ /sbin/lsmod 
  Module:        #pages:  Used by:
  floppy            11    0 (autoclean)

The "(autoclean)" means that the module will automatically be removed by kerneld when it has not been used for more than one minute. So the 11 pages of memory (= 44kB, one page is 4 kB) will only be used while I access the floppy drive - if I don't use the floppy for more than a minute, they are freed. Quite nice, if you are short of memory for your applications!

Block devices

If you run /sbin/modprobe -c, you will get a listing of the modules that kerneld knows about, and what requests they correspond to. For instance, the request that ends up loading the floppy driver is for the block-device that has major number 2:

  osiris:~ $ /sbin/modprobe -c | grep floppy
  alias block-major-2 floppy

Why block-major-2 ? Because the floppy devices /dev/fd* use major device 2 and are block devices:

  osiris:~ $ ls -l /dev/fd0 /dev/fd1
  brw-rw-rw-   1 root     root       2,   0 Mar  3  1995 /dev/fd0
  brw-r--r--   1 root     root       2,   1 Mar  3  1995 /dev/fd1

Character devices

Character devices are dealt with in a similar way. E.g. the ftape floppy tape driver sits on major-device 27:

  osiris:~ $ ls -lL /dev/ftape 
  crw-rw----   1 root     disk      27,   0 Jul 18  1994 /dev/ftape

However, kerneld does not by default know about the ftape driver - it is not listed in the output from /sbin/modprobe -c. So to setup kerneld to load the ftape driver, I must add a line to the kerneld configuration file, /etc/conf.modules:

  alias char-major-27 ftape

Network devices

You can also use the device name instead of the char-major-xxx or block-major-yyy setup. This is especially useful for network drivers. For example, a driver for an ne2000 netcard acting as eth0 would be loaded with

  alias eth0 ne

If you need to pass some options to the driver, for example to tell the module about what IRQ the netcard is using, you must add an "options" line:

  options ne irq=5

This will cause kerneld to load the NE2000 driver with the command

  /sbin/modprobe ne irq=5

Of course, the actual options available are specific to the module you are loading.

Binary formats

Binary formats are handled in a similar way. Whenever you try to run a program that the kernel does not know how to load, kerneld gets a request for binfmt-xxx, where xxx is a number determined from the first few bytes of the executable. So, the kerneld configuration to support loading the binfmt_aout module for ZMAGIC (a.out) executables is

  alias binfmt-267 binfmt_aout

Since the magic number for ZMAGIC files is 267, if you check /etc/magic, you will see the number 0413; keep in mind that /etc/magic uses octal numbers where kerneld uses decimal, and octal 413 = decimal 267. There are actually three slightly different variants of a.out executables (NMAGIC, QMAGIC and ZMAGIC), so for full support of the binfmt_aout module we need

  alias binfmt-264 binfmt_aout  # pure executable (NMAGIC)
  alias binfmt-267 binfmt_aout  # demand-paged executable (ZMAGIC)
  alias binfmt-204 binfmt_aout  # demand-paged executable (QMAGIC)

a.out, Java and iBCS binary formats are recognized automatically by kerneld, without any configuration.

Line disciplines (slip, cslip and ppp)

Line disciplines are requested with tty-ldisc-x, with x being usually 1 (for SLIP) or 3 (for PPP). Both of these are known by kerneld automatically.

Speaking of ppp, if you want kerneld to load the bsd_comp data compression module for ppp, then you must add the following two lines to your /etc/conf.modules:

  alias tty-ldisc-3 bsd_comp
  alias ppp0 bsd_comp

Network protocol families (IPX, AppleTalk, AX.25)

Some network protocols can be loaded as modules as well. The kernel asks kerneld for a protocol family (e.g. IPX) with a request for net-pf-X where X is a number indicating what family is wanted. E.g. net-pf-3 is AX.25, net-pf-4 is IPX and net-pf-5 is AppleTalk; These numbers are determined by the AF_AX25, AF_IPX etc. definitions in the linux source file include/linux/socket.h. So to autoload the IPX module, you would need an entry like this in /etc/conf.modules:

  alias net-pf-4 ipx

See Common Problems for information about how you can avoid some annoying boot-time messages related to undefined protocol families.

File systems

kerneld requests for filesystems are simply the name of the filesystem type. A common use of this would be to load the isofs module for CD-ROM filesystems, i.e. filesystems of type iso9660:

  alias iso9660 isofs

char-major-10 : Mice, watchdogs and randomness

Hardware devices are usually identified through their major device numbers, e.g. ftape is char-major-27. However, if you look through the entries in /dev for char major 10, you will see that this is a bunch of very different devices, including

• Mice of various sorts (bus mice, PS/2 mice)

• Watchdog devices

• The kernel random device

• APM (Advanced Power Management) interface

These devices are controlled by several different modules, not a single one, and therefore the kerneld configuration for these misc. devices use the major number and the minor number:

        alias char-major-10-1 psaux     # For PS/2 mouse
        alias char-major-10-130 wdt     # For WDT watchdog

You need a kernel version 1.3.82 or later to use this; earlier versions do not pass the minor number to kerneld, making it impossible for kerneld to figure out which of the misc. device modules to load.

Loading SCSI drivers: The scsi_hostadapter entry

Drivers for SCSI devices consist of a driver for the SCSI host adapter (e.g. an Adaptec 1542), and a driver for the type of SCSI device you use, e.g. a hard disk, a CD-ROM or a tape-drive. All of these can be loaded as modules. However, when you want to access e.g. the CD-ROM drive that is connected to the Adaptec card, the kernel and kerneld only knows that it needs to load the sr_mod module in order to support SCSI CD-ROM's; it does not know what SCSI controller the CD-ROM is connected to, and hence does not know what module to load to support the SCSI controller.

To resolve this, you can add an entry for the SCSI driver module to your /etc/conf.modules that tells kerneld which of the many possible SCSI controller modules it should load:

        alias scd0 sr_mod               # sr_mod for SCSI CD-ROM's ...
        alias scsi_hostadapter aha1542  # ... need the Adaptec driver

This only works with kernel version 1.3.82 or later.

This works if you have only one SCSI controller. If you have more than one, things become a little more difficult.

In general, you cannot have kerneld load a driver for a SCSI host adapter, if a driver for another host adapter is already installed. You must either build both drivers into your kernel (not as modules), or load the modules manually.

You should be aware, that this technique only works if you have different kinds of SCSI devices on the two controllers, for example, hard disks on one controller, and cd-rom drives, tapes or generic SCSI devices on another.

When loading a module isn't enough: The post-install entry

Sometimes, just loading the module is not enough to get things working. For instance, if you have your sound card compiled as a module, it is often convenient to set a certain volume level. Only problem is, the setting vanishes the next time the module is loaded. Here is a neat trick from Ben Galliart (<bgallia@luc.edu>):

The final solution required installing the setmix package and then adding the following line to my /etc/conf.modules:

post-install sound /usr/local/bin/setmix -f /etc/volume.conf

What this does is that after the sound module is loaded, kerneld runs the command indicated by the post-install sound entry. So the sound module gets configured with the command /usr/local/bin/setmix -f /etc/volume.conf.

This may be useful for other modules as well, for example the lp module can be configured with the tunelp program by adding

        post-install lp tunelp options

For kerneld to recognize these options, you will need a version of kerneld that is 1.3.69f or later.