FreeBSD 6 Unleashed

At the time of this writing, FreeBSD doesn't have a visual kernel configuration utility like the make xconfig dialog-driven process in various Linux distributions. FreeBSD's kernel is configured using text files, a method that may seem quite arcane but one that does provide some flexibility the visual methods don't.

A visual configuration tool provides interactive feedback, allowing you to enable and disable devices and options on a case-by-case basis. What it doesn't do, though, is allow you to maintain multiple configurations side by side, comparing them using tools such as diff and grep, and use the base-level GENERIC configuration, previous known valid configurations, and the reference NOTES files as guidelines. Using a text file configuration also allows you to see all your device options at a glance.

An interactive visual tool can become needlessly complex and convoluted, and in asking you to decide individually whether to include every different option, it actually can detract from useful feedback. Unless you can remember the importance and consequences of every different option available in the config file, it's hard to keep track of which options you should be selecting. With the FreeBSD method, you can tune your config file until you're happy with it, incorporating changes introduced since the release of a previous version. You can even copy a "standard" configuration from another FreeBSD system and then build the kernel from it.

Assuming you installed the FreeBSD sources on your system, go into the /usr/src/sys/i386/conf directory, the location for the kernel config files. There you'll see the GENERIC file, among other items.

Note

If you're running on Alpha hardware instead of x86, use alpha in the previous pathname instead of i386. The same goes for IA64, SPARC, or PowerPC hardwarego into the appropriately labeled directory in /usr/src/sys. A number of other details in this chapter will be slightly different as well, but the process remains the same.

The GENERIC Configuration File

Open up the GENERIC file in your favorite text editor. Scroll through the various options, but don't actually make any changes just yet (you don't want to alter the GENERIC file itself). You'll see that there's a lot of built-in redundancy in the file in order to make sure your system remains compatible with all kinds of machines. The block of lines near the top of the file will resemble the following, although it will vary depending on your specific version of FreeBSD:

machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GENERIC

The machine line, ident line, and one of the cpu linesthe one most appropriate to your hardwaremust be present in the file for the kernel to run. If you have a high-end Pentium, for example, you can remove the legacy I486_CPU and I586_CPU lines, and you may achieve some performance gains in the process.

Note

The cpu line is specific to your computer's architecture, and tells FreeBSD what kind of kernel to build. In the GENERIC file for IA64 hardware, the cpu value is ITANIUM; for PowerPC, it's OEA; for SPARC, it's SUN4U; and so on.

Below this block are the options linesoptional features that are built into the GENERIC kernel by default, given in Listing 18.2 (a FreeBSD 6.0 kernel is shown). Although these lines don't have to be present in order for the kernel to be valid, it just wouldn't be a very useful kernel without them. Removing certain options can improve your system's performance, but it can also break key features such as Access Control Lists, CD-ROM support (the ISO9660 filesystem), TCP/IP networking, and a raft of built-in and third-party programs that depend on SysV-style memory management and signaling, such as Oracle for Linux and PostgreSQL. Meddle with these options only if you know what you're doing!

Listing 18.2. Built-in GENERIC Kernel Options

The remainder of the file is taken up with device lines. These lines specify all the hardware device drivers the GENERIC kernel has built-in, and there are a lot of them. These are mostly what you will want to strip out of your custom kernel in order to optimize it (they're certainly the safest to remove). For instance, if you know your Ethernet card is an Intel EtherExpress series (handled by the fxp driver), you can disable every other PCI Ethernet driver in this block. Listing 18.3 shows a sample block of device lines, of which there are several in the file.

Listing 18.3. Some of the Device Drivers Built into the GENERIC Kernel

Device Hints

FreeBSD operates using the Device Filesystem (DEVFS) and device hints, which provide a way of abstracting the attributes of various devices so that the system can find them without needing the attributes to be compiled statically into the kernel. These attributes used to be defined like this, in the kernel config file itself:

device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15

Now, however, the kernel configuration file only needs to have this line:

device ata

This change happened because the ata device has its attributes stored in the /boot/device.hints file, which is consulted by the kernel at boot time. Here are the relevant lines of that file for this example:

hint.ata.0.at="isa" hint.ata.0.port="0x1F0" hint.ata.0.irq="14" hint.ata.1.at="isa" hint.ata.1.port="0x170" hint.ata.1.irq="15"

With these attributes kept in a central location, the kernel knows on what bus, memory address, and IRQ (interrupt request) to find the ata device. Also, you can change these attributes without having to recompile the kernel. If you prefer, though, you can still compile the attributes statically into the kernel by enabling this line:

#To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices.

The /etc/rc.d/devfs script is run at boot time and controls after-the-fact symlinking and permissions tweaks that normally need to be done only once in a static, non-DEVFS system (you learn about how configuration scripts like /etc/rc.d/devfs are executed in Chapter 14, "System Configuration and Startup Scripts").

DEVFS simplifies many UNIX housekeeping tasks that used to be very onerous. However, there are cases where it can lead to you having to do more work than would otherwise be the case. For instance, a common task in setting up a UNIX installation is to symlink /dev/mouse to /dev/psm0, or /dev/dvd to /dev/acd0c, because certain software expects to use the more generic device names; this way you don't have to configure the systemspecific devices into that software. A DVD player application will expect to find /dev/dvd, not a device label that can vary from system to system. Also, because some devices (such as DVD-R burners) must have the proper permissions so that certain userstypically those in the groups that own these devicescan write to them, the permissions on the devices must be altered with a chmod command.

Traditionally, you would issue the following commands during installation to set up /dev/dvd, after which you would never have to worry about it again:

# chmod 664 /dev/acd0c # ln -sf /dev/acd0c /dev/dvd # ln -sf /dev/acd0c /dev/rdvd

Nowadays, though, with DEVFS, the /dev/acd0c device is set up dynamically each time you boot, and so your previously configured symlinks would be invalid. To achieve the same effect as with earlier systems, you simply add these three lines to /etc/rc.d/devfs at the end of the file, and they will be applied after the dynamic devices are created.

The NOTES Files and LINT

Fortunately, you aren't on your own when it comes to identifying each of these uglylooking options and devices, or knowing which other ones are available. A file called NOTES, also in /usr/src/sys/i386/conf, describes all possible options and devices available in the current system. It's another file that you don't want to modify. Just open it in less and look through its contents. You'll find explanations of all the lines in the GENERIC kernel, as well as a lot more available options and devices that you can add to the kernel configuration if you so choose.

A second NOTES files, residing in /usr/src/sys/conf, is a hardware-independent version that contains all the kernel options that don't apply specifically to your system's architecture. For example, whereas in the NOTES file in the i386 subtree you'll find the documentation of lots of options for controlling specific Intel CPU features, as well as the x86-style ISA, PCI, and AGP buses and other hardware components, for general FreeBSD features such as filesystems and memory management you'll need to look in the deviceindependent NOTES file.

Everything in GENERIC has an entry in one of the NOTES files as well. You can theoretically copy any configuration line (that begins with anything other than hint) into your custom kernel config file and then run with it. This will generally be necessary only if you add some particularly unusual device or kernel option, but NOTES is the first thing you should consult in that event.

NOTES also contains device hint lines; these are the ones beginning with hint (as described previously). You can copy these lines either into /boot/device.hints or into the hints file for your kernel (for example, GENERIC.hints) if you want to compile them in statically.

Many items in both NOTES files refer to a mysterious thing called LINT. This is an old, deprecated (pre-FreeBSD 5.0) way of looking at what is now the NOTES file. LINT was named after the lint commanda C-code debugging utility that's named for the idea that it validates the code you run it on by removing excess lint and fuzz from it. One of the long-running ideals (or myths) about FreeBSD is that it offers the capability to build a kernel based on the LINT file, incorporating every possible supported option and driver. This useless feat of UNIX-geekdom is almost certainly not possible these days, because many of the kernel options are mutually exclusive or unstable, and because nobody actually tries to ensure that it can be done. FreeBSD does, however, provide the capability to generate an old-style LINT file by running make LINT from within the directory. This strips out all comments and hint. lines, and creates a kernel config file that you can theoretically use to build a huge, all-encompassing kernel that probably won't have a chance of booting or even compiling.