UNIX System Administration Handbook - Evi Nemeth [141]
Linux is a bit of a cross between Solaris and BSD. Like FreeBSD, Linux is crippled by the PC environment, in which it’s difficult to take an accurate inventory of the system’s hardware. You can configure a Linux kernel just as you configure a FreeBSD kernel, telling it all about your hardware beforehand and making one giant kernel. Or, you can configure Linux to behave more like Solaris and load most of its drivers only when needed. Linux’s module support is limited compared to Solaris, but many of its limitations have been dictated by the restrictions of PC hardware.
Table 12.1 shows the location of the kernel build directory and the standard name of the installed kernel on each of our example systems.
Table 12.1 Kernel build directory and location by system
12.2 WHY CONFIGURE THE KERNEL?
When the system is installed, it comes with a generic kernel that’s designed to run on most any hardware. The generic kernel includes many different device drivers and option packages. Since the kernel only needs to run on your particular system, it’s a good idea to reconfigure it to get rid of the modules you won’t be using and to turn off options that don’t interest you.
Building a kernel tailored to the system is a good habit to get into. Your well-tuned configuration, once attained, can serve as a reference guide for the system’s hardware. Although unused features and drivers might not interfere directly with the operation of the system, they can still consume memory.
Modern kernels are better than their predecessors at flushing unwanted drivers from memory, but compiled-in options will always be turned on. Although reconfiguring the kernel for efficiency reasons is less important than it used to be, a good case can still be made for doing so.
Another reason to reconfigure the kernel is to add support for new types of devices (i.e., to add new device drivers). The driver code can’t just be mooshed onto the kernel like a gob of Play-Doh; it has to be integrated into the kernel’s data structures and tables. On some systems, this procedure may require that you go back to the configuration files for the kernel and add in the new device, rebuilding the kernel from scratch. On other systems, you may only need to run a program designed to make these configuration changes for you.
Instructions for adding a new driver start on page 246.
Some systems include the concept of a “loadable” device driver, in most cases implying that new code can be loaded into the kernel while it is running. A good human analogy might be having brain surgery while operating heavy machinery.
Building a kernel is not difficult; it’s just difficult to fix when you break it.
12.3 CONFIGURING A SOLARIS KERNEL
At boot time, the Solaris kernel probes the machine for devices and initializes a driver for each device it finds. It makes extensive use of loadable modules and loads code only for the devices that are actually present, unless forced to do otherwise.
Depending on your point of view, this automatic configuration makes configuring a custom kernel more or less of a necessity under Solaris than on other systems. In an ideal world, the kernel would correctly identify its hardware environment 100% of the time. Unfortunately, flaky, nonstandard, or just plain buggy hardware (or Solaris drivers) can turn this creature comfort into a torment.
That said, let’s look at how to custom-configure a Solaris kernel, should you ever need to do so.
The Solaris kernel area
To make on-demand module loading work correctly, Solaris relies heavily on a particular directory organization. Solaris expects to find certain directories in certain places, and these directories must contain specific types of modules:
• /kernel – modules common to machines that share an instruction set
• /platform/platform-name/kernel – modules specific to one type of machine, such as an Ultra Enterprise
• /platform/hardware-class-name/kernel