The Role of the Kernel

The kernel is the master executable of the system. It's the first thing that is executed from the boot blocks when you power on the system, and it constantly runs throughout the machine's uptime. Its job is to oversee all the processes running on the system, handle TCP/IP and other networking duties, manage access to all the devices on the system, and control memory usageto name just a few hats it wears.

Every operating system since the beginning of computing has had a kernel. Whether it's an ancient and rudimentary platform like the Apple ][ or a 286-based PC running MS-DOS, a desktop operating system like Mac OS X or Windows XP, or a high-end multiprocessor mainframe, there's always a kernel handling all the heavy lifting behind the scenes of your user applications. Some systems take greater pains to hide the kernel from the user than others do. In Windows, it's an executable in C:\WINDOWS\SYSTEM; in Mac OS X, though, it's protected by a hierarchy of hidden folders known only to experts, and in classic Mac OS it's hidden from the filesystem entirely. In many UNIX systems, the kernel's traditional place is in the root directory at the top of the filesystem. In FreeBSD, the kernel was placed in / prior to FreeBSD 5.0 and in /boot afterward. With each of these operating systems, a default (or "generic") kernel is part of every released version of the system; when a new version comes out, its changes are mostly additions to accommodate drivers for new devices that the system supports. The kernel is responsible for knowing about every kind of device that can be connected to the system.

When you install drivers for a new and previously unsupported device in Windows, you generally have to reboot. That's because the drivers, libraries, and other items used by your kernel have been modified and cannot be incorporated into the system's operation on the fly. In most cases, the system has to be restarted in order for the new resources to be used.

FreeBSD, by contrast to Linux, classic Windows and Mac OS, and some others, uses a microkernel architecture, which means that the kernel is fairly small and modular. Windows NT/2000/XP and Mach (the kernel upon which Mac OS X is built) are other examples of microkernels in which new devices are more frequently added through kernel modules (which can be loaded and unloaded during runtime) than by recompiling the kernel. Windows 95/98/Me (and, in past versions, Linux) are instead monolithic kernels, in which the kernel's code is more optimized for performance and to minimize context switching. The monolithic kernel architecture makes for kernel code that's fast in execution, but it tends to be ungainly and difficult for developers to maintain, and the administrator is required to recompile the kernel every time support for a new device is added.

It isn't terribly easy to identify a microkernel or a monolithic kernel in today's operating system landscape. Linux operates fairly heavily on kernel modules today, and FreeBSD's kernel does have to be recompiled for a number of different reasons. The difference between a microkernel and monolithic kernel architecture is largely a philosophical one and has to do with a good deal more than simply device support, andnaturallyno kernel lives up perfectly to its philosophical ideals. The biggest and most fundamental difference between the two kernel architectures is that a microkernel has a mechanism for passing certain non-core system calls to a user-level processing level, or ring, instead of handling them all internally and stripping down the core of the kernel to only those functions that require the highest level of supervisor-mode execution status. Keeping only essential functions in the kernel increases runtime robustness and makes the kernel processes more understandable and manageable. This arrangement also provides a measure of inherent security in the form of reduced complexity as well as easier support for modular device driver code. The bottom line is that a microkernel is like object-oriented programming: it might not run as fast as a pure procedural or monolithic program, but it sure is easy to put together quickly from basic components.

Although the ideal of total modularity is all well and good, a kernel in which every possible kind of device and option is modular and loadable during runtime is as theoretical as perpetual motion. Chances are that as you gain experience with FreeBSD, you will come to a point where you can't avoid recompiling your kernel; it's at that time that you'll undergo the rite of passage that initiates you into the circle of kernel hackers.

This chapter begins with an introduction to kernel modules and how to extend FreeBSD's microkernel on the fly; then it moves on to the far more involved tasks that are necessary for recompiling your kernel from sources to match your system's needs.