Why Configure a Custom Kernel?
| FreeBSD comes with the GENERIC kernel installed by default. This kernel is tuned to support as wide a user base as possible so that FreeBSD will work out of the box on as many different machines as there are users in the world. Given the nature of x 86-based hardware, this means that the FreeBSD kernel must hold a truly astounding number of built-in drivers. An operating system built for a tightly controlled set of hardware (such as SGI's IRIX or Apple's Mac OS X) can afford to get away with much less of this generic support, but FreeBSD is stuck with it. The GENERIC kernel also has various options for memory allocation and optimization set to lowest-common-denominator levels, and other optional elements are left out in order to keep the kernel as streamlined as possible under the circumstances. These are all aspects of the kernel that can almost certainly be configured more efficiently for your particular system. Note One reason for having as many devices compiled into the GENERIC kernel as possible is to ease installation; you don't want to boot into a stripped-down installation kernel, hoping to do a network install, only to find that your Ethernet card isn't supported in the kernel! Streamlining the KernelThe kernel probes at boot time for every single kind of device it knows about. This is where you see that scrolling screen full of white text while the system is coming up; the kernel is looking for dozens of different kinds of devices that are enabled in the GENERIC kernel. Although it doesn't hurt anything for the kernel not to find most of them, it does take time to perform each probe. You can speed up boot time significantly by removing the unnecessary devices from the kernel. This also helps reduce the size of the kernel. Modern systems with gigabytes of RAM don't need to worry about this streamlining, but it's a worthy consideration on a machine that barely meets FreeBSD's minimum requirements. As you add devices such as USB peripherals, sound cards, SCSI controllers, and others to your system, you won't be able to use many of them unless you add support for them in the kernel. The same is true of new filesystem types (such as Linux's EXT2FS, as you saw in Chapter 12, "The FreeBSD Filesystem"). Many devices and filesystems are available today as kernel modules, but the majority still have to be compiled into the kernel, so you have little choice but to rebuild it. However, rebuilding gives you the chance to tweak other things in the system (such as the number of memory buffers, custom memory management features, and the kernel's name), so you can enhance your system's performance significantly with one rebuild. Note Symmetric Multi-Processing (SMP) support is not present in the GENERIC kernel either. If you have a system with more than one CPU or processor core, you'll need to build a custom kernel in order to take advantage of all of them. Using dmesg to Get Information About the Kernel StartupIf you will be stripping unnecessary devices out of your kernel, it is imperative that you find out what devices you do have so that you don't end up accidentally removing support for your existing hardware. As mentioned earlier, the kernel probes for all its known devices at boot time, and it prints out the status of each probe, telling you which devices you must keep in the new kernel. This information isn't just printed out to the screen at boot time; it's also echoed into an internal runtime message buffer for reference at any time. The tool to use for recalling this information is dmesg. The output of dmesg can be very long, so you'll probably want to pipe it through less, as shown in Listing 18.1. Listing 18.1. Partial Output from dmesg Piped Through less for Improved Readability
Tip If your system has been online for a long time, the boot messages might have scrolled out of the dmesg buffer; however, you can always see the messages from the last boot in /var/run/dmesg.boot. The output continues throughout all device checks, filesystem validations, and daemon startup blocks and then continues into runtime errors generated by various devices since you booted. You can ignore everything after you begin seeing date stamps and regular error messages. What you're interested in is the boot messages, such as the ones in the preceding listing. The first part of the boot messages, after the copyright and CPU information lines, is the kernel configuration you have set in the boot configurator. Each line beginning with config>, if present, is a command you issued in visual config mode, most likely (as with the di lines) to delete unwanted devices from the probe process. These devices won't appear later in the dmesg output. If you haven't removed these devices in the configurator, the kernel will probe for them. Any driver accompanied in the listing by a "not found" message is a driver you can delete from the kernel. You may want to keep two SSH terminal windows open to your FreeBSD machine: one to read the output of dmesg and another to configure the kernel. This will help ensure you don't delete anything that the system reports as "found." |
on pci0 pcib1: <PCI-PCI bridge> at device 1.0 on pci0 pci1: <PCI bus> on pcib1 $PIR: ROUTE_INTERRUPT failed. pci1: <display, VGA> at device 0.0 (no driver attached) isab0: <PCI-ISA bridge> at device 7.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <Intel PIIX4 UDMA33 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 