Kernel Modules

FreeBSD comes with several dozen kernel modules in its standard configuration, all located within the /boot/kernel directory along with the kernel file itself, and each one representing some new functionality or device support that is not necessarily present in the default (GENERIC) kernel. These kernel modules, files with extensions of .ko (for "kernel object"), can be loaded or unloaded at any time by the root user, adding features such as the ability to read a non-standard filesystem type or to use an unusual Ethernet card.

As an example, let's consider the smbfs.ko module. This module, as its name suggests, provides support for the SMB Filesystem (the filesystem type underlying Windows network file-sharing), which isn't available in the GENERIC kernel. Suppose there's a Windows machine on the network that's sharing a disk resource that you want to mount and read as a normal filesystem. To do this, you'll need to add SMBFS support to the kernel. This is done with the kldload command:

# kldload smbfs

Normally there is no output from a kldload command. However, you can use kldstat to determine whether the module was loaded correctly:

# kldstat Id Refs Address    Size     Name  1   10 0xc0400000 63070c   kernel  2   16 0xc0a31000 568dc    acpi.ko  3    1 0xc16ed000 15000    linux.ko  4    1 0xc2693000 1b000    smbfs.ko  5    2 0xc1bc6000 3000     libiconv.ko  6    2 0xc1bdc000 3000     libmchain.ko

This output tells you a number of things. First it lists the modules that were present before we loaded the smbfs module: the kernel itself, followed by the ACPI driver (which supports the power management features on newer hardware), and then the linux.ko module that provides Linux binary compatibility. Then there's the smbfs.ko module that was just loaded, followed by two more modules that are necessary for the proper function of the SMBFS module and are loaded implicitly as dependencies: libiconv and libmchain.

Tip

Most kernel modules' purposes are described in man pages that you can access using the name of each module minus the .ko extension (for example, man smbfs). Others, such as the libiconv.ko library, are listed without the lib prefix (for example, man iconv).

The size of each module is given in hexadecimal format; you can decode the number next to each one to see how much memory each one is using up. Some kernel modules take up a lot of memory; others might slow down the kernel's operation. These are just a couple of the many reasons why you might want to remove a module from the kernel after you're done using its functionality; this is done using the kldunload command:

# kldunload smbfs

Loading a kernel module is usually a quick and straightforward process. Many modules are designed to be loaded automatically if their functionality is called for by a command that requires it, such as the mount_* commands that mount various filesystem types that aren't compiled into the GENERIC kernel; when you use these commands, you might not even realize that a kernel module has been loaded. However, on older hardware, or on an already heavily modified kernel, or if the module is less than stable (the smbfs.ko module is itself very shaky), the process of adding a module is anything but transparent. Sometimes it takes a long time to load the module, blocking your user input; and sometimes it conflicts with existing kernel features and can even crash your computer.

If a kernel module that you find yourself using frequently takes a long time to load on the fly, or if you just don't want to have to worry about loading it all the time, you can have FreeBSD load it automatically at boot time. To do this, add a statement for each such kernel module's name in the /boot/loader.conf file:

smbfs_load="YES" msdosfs_load="YES"

The first part of each statement is the name of the kernel module (minus the .ko extension), and it's followed by an underscore and load="YES". This ensures that the specified modules are loaded at boot time and the commands that depend on them will always work.

Even this, though, might not suit your needs. Some modules might be too flaky to load on a regular basis; some might even cause crashes or unexpected reboots, or might disable your machine's network connectivity. To add their functionality to your kernel without having to bother with the uncertainties of kernel modules, you'll need to build a custom kernel, as detailed in the remainder of this chapter.