Kernel Configuration Database 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

Both UNIX platforms, BSD and System V, use the kernel configuration files to specify and keep configuration data. Traditionally the configuration data had to be compiled into the kernel binary for 567 Specifying an entry in the kernel configuration database does not mean that the system must possess the corresponding hardware device or peripheral. It means that the kernel will be ready to support such device or peripheral if it is attached to the system. In other words, specifying an entry in the kernel configuration file will enable the appropriate systems function. The system checks its current hardware configuration during its startup and initializes activates all existing devices and peripherals. However, if the entry for an existing device is missing in the kernel configuration file, the system cannot support this device at all. One might think that a kernel configuration file should contain all possible entries, so we can be sure that any system hardware configuration will be supported. This is a nice idea, but such an approach will create a large, memory−consuming, slow−to−execute kernel image do not forget that the kernel is a memory−resident program. Nevertheless, this is a trend among modern versions of UNIX. On the other hand, the approach of stripping a kernel configuration down to the existing systems exact hardware configuration can result in a restrictive kernel, inflexible for future system upgrades. Like everything in life, a satisfactory compromise should be achieved. It is important to make a strict distinction between a kernel configuration file and the kernel itself. A kernel configuration file is an ASCII file that defines all kernel nondefault data and arguments. A kernel or rather, a kernel image is an image of the built kernel, a memory−resident executable that provides the interface between system hardware and the operating system. Modifying the kernel configuration file does not mean modifying the kernel itself; one more step is required: to compile, i.e., to rebuild, the kernel Solaris is an exception because it rebuilds the kernel online.

23.3 BSD−Like Kernel Configuration Approach