Chapter 16. Configuring and Building Kernels


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:

  • Process creation, termination and scheduling

  • Virtual memory management (including paging)

  • Device I/O (via interfaces with device drivers: modules that perform the actual low-level communication with physical devices such as disk controllers, serial ports, and network adapters)

  • Interprocess communication (both local and network)

  • Enforcing access control and other security mechanisms

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:

  • To add capabilities to the kernel (e.g., support for disk quotas or a new filesystem type)

  • To add support for new devices

  • To remove unwanted capabilities/features from the kernel to reduce its size and resource consumption (mostly memory) and thereby presumably improve system performance

  • To change the values of hardwired kernel parameters that cannot be modified dynamically

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

figs/armadillo_tip.gif

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:

  • Installing the kernel source code package (if necessary)

  • Applying any patches, adding new device driver code, and/or making any other source code changes you may require

  • Saving the current kernel and its associated configuration files

  • Modifying the current system configuration as needed

  • Building a new kernel executable image

  • Building any associated kernel modules (if applicable)

  • Installing and testing the new kernel

Table 16-1 lists the kernel locations and kernel build directories for the operating systems we are considering.

Table 16-1. Standard kernel image and build directory locations
 

Kernel

Configuration or build directory

AIX

/unix

none

FreeBSD

/kernel

/usr/src/sys/i386/conf[1]

HP-UX

/stand/vmunix

/stand/build

Linux

/boot/vmlinuz

/usr/src/linux

Solaris

/kernel/unix (or genunix[2])

none

Tru64

/vmunix or /genvmunixb

/usr/sys/conf

[1] This component is architecture-specific; i386 is the generic subdirectory for Intel-based PCs. If you're running on a more recent CPU type, building a kernel for that specific processor may improve the operating system's performance.

[2] The gen forms are the generic, hardware-independent versions of the kernel.

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

figs/armadillo_tip.gif

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.



Essential System Administration
Essential System Administration, Third Edition
ISBN: 0596003439
EAN: 2147483647
Year: 2002
Pages: 162

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net