Introduction to Kernel Reconfiguration

Chapter 23: Kernel Reconfiguration

23.1 Introduction to Kernel Reconfiguration

The UNIX kernel is the part of the UNIX operating system that manages the system hardware. Kernel presents control software between OS and the underlying hardware, merging all system devices into a functional OS controllable system. Kernel remains memory resident while the system is up; otherwise a system would behave very poorly. We have already talked about the kernel in Chapter 4 when we discussed system startup. Then we learned that the executable image of the kernel is invoked after a bootstrap program execution and it continues to run at all times. Now, we return to this topic to elaborate the duties of the system administrator regarding the kernel. The kernel is a site−dependent, memory resident executable program; this means the kernel must be appropriately configured for a particular UNIX system implementation. Each installed UNIX system also has a configured kernel; this is usually a generic kernel compliant for most system implementations. However, site−specific conditions and a special system mission could require different, more appropriate kernel configuration. Then we have to change an existing kernel, and we talk about kernel reconfiguration. Generally, reconfiguring the kernel means to create, or to modify, an appropriate kernel configuration file, which defines the kernel correspondingly. In most cases it also means to compile a reconfigured kernel afterward. All changes in a kernel become effective upon rebooting the system, because the newly configured kernel could be invoked only at the next system startup; there is no way to change an actual memory resident kernel image. As a matter of fact, a kernel reconfiguration presents a routine procedure defined by UNIX designers that an administrator should strictly follow. There is not a lot of freedom in implementing this procedure; the existing rules must be fully respected, or our kernel reconfiguration will fail. A failed kernel also means a sick UNIX system, sometimes even a not−bootable one. An administrator must know how to handle such situations; a full understanding of this procedure is very instrumental in doing this successfully. It raises a crucial question, how to bring the system back from a bad kernel to the previously workable one. We must always be prepared for the worst−case scenario. BSD and System V have very different kernel configuration files and reconfiguration procedures. Also, within each of these two UNIX platforms, significant variations exist among different vendors. That is why it is probably more appropriate to talk about vendor−flavored kernel reconfiguration. Nevertheless, we will try to keep continuity with earlier chapters — partially by following this topic historically, and partially by elaborating on the dominant modern UNIX flavors. The nature of a kernel makes it almost impossible to create a universal kernel applicable to any situation. Different hardware configurations require different kernel configurations, and some trade−off must be found. Some systems are shipped with a minimal kernel, so changes may be needed when new hardware or software is added. Usually when new software is installed, the kernel changes, if required, are performed automatically by the installation procedure. This is also the case when OS patches are implemented if the patches are kernel related. In both cases, to become effective, a system reboot is required after implementation.

23.2 Kernel Configuration Database