As we've noted many times before, the kernel is the heart of the Unix operating system. It is the core program, always running while the operating system is up, providing and overseeing the system environment. Thekernel is responsible for all aspects of system functioning, including:
Traditionally, the Unix kernel is a single, monolithic program. On more recent systems, however, the trend has been toward modularized kernels: small core executable programs to which additional, separate object or executable files modules can be loaded and/or unloaded as needed. Modules provide a convenient way to provide support for a new device type or add specific new functionality to an existing kernel. In many instances, the standard kernel program provided with the operating system works perfectly well for the system's needs. There are a few circumstances, however, where it is necessary to create a custom kernel (or perform equivalent customization activities) to meet the special needs of a particular system or environment. Some of the most common are:
How often you have to build a new kernel depends greatly on which system you are administering. On some older systems (mid-1990s versions of SCO Unix come to mind), you had to build a new kernel any time you added even the smallest, most insignificant new device or capability to the system. On most current systems, such as FreeBSD and Tru64, you build a kernel only when you want to significantly alter the system configuration. And on a few systems, like Solaris and especially AIX, you may never have to do so. In this chapter, we'll look at the process of building a customized kernel, and we'll also examine administering kernel modules. There are many reasons you might want to alter the standard kernel: addressing performance issues, supporting a device and subsystem, removing features the system doesn't use (in an effort to make the kernel smaller), adjusting the operating system's behavior and resource limits, and so on. We won't be able to go into every possible change you might make on each of the systems we are considering. Instead, we'll look at the general process you go through to make a kernel, including how to install it and boot from it and how to back out your changes should they prove unsatisfactory. NOTE
Custom kernel building and reconfiguration is not for the faint-hearted, the careless or the ignorant. Know what you're doing, and why, to avoid inadvertently making your system unusable. In general, building a custom kernel consists of these steps:
Table 16-1 lists the kernel locations and kernel build directories for the operating systems we are considering.
We'll begin with the kernel build process on FreeBSD and Tru64 systems (which are very similar) and then consider each of the other environments in turn. In each case, we will also consider other mechanisms for configuring the kernel and/or kernel modules that are available. NOTE
It is possible on many systems to change some kernel parameters while the system is running. We'll look at those mechanisms in this chapter as well. You will also want to review the discussion of the /proc filesystem in Section 15.2. |