For example, to allow users to mount filesystems by setting the vfs.user−mount sysctl, add the following on a line by itself in sysctl.conf.

...............................................................................................

vfs.usermount=1

...............................................................................................

Kernel Configuration with Loader.conf

Some kernel configuration must take place before the system starts to boot. For example, when the kernel initially probes an IDE hard drive, the device driver determines whether or not to use write caching. This decision must be made when the drive is first detected, during boot, and you can't change your mind after booting. Similarly, you might have a new network card and want to load the kernel module for its driver before you boot. That's where the system loader comes in.

The loader has many functions: It finds the hard drive that contains the kernel, loads the kernel into memory, triggers the booting process, and feeds information to the kernel. The most important part of the information the loader feeds to the kernel is the sysctl MIBs, which must be set at boot.

The most common way to configure the system loader is to edit a configuration file, though you can also enter configuration commands manually at the loader's ok> prompt. For long−term changes, you're better off including them in /boot/loader.conf.

There are two important loader.conf files: /boot/loader.conf and /boot/defaults/loader.conf. We'll have a look at the second of the two in Chapter 8. For now, we'll change /boot/loader.conf only. The entries in /boot/defaults/loader.conf are the system defaults; anything you put in /boot/loader.conf will override the default settings.

Loader.conf has two main functions: loading kernel modules and providing hints to device drivers. The device driver hints are generally sysctl MIBs that can only be set at boot.

When you look at /boot/defaults/loader.conf, you'll see a lot of options that you might find useful in various circumstances, such as the ability to specify a different kernel rather than the default, or the ability to specify verbose booting. Just for reference, here's a snippet of /boot/defaults/loader.conf.

...............................................................................................

kernel="/kernel" kernel_options=""

userconfig_script_load="NO" userconfig_script_name="/boot/kernel.conf" userconfig_script_type="userconfig_script"

. . .

...............................................................................................

To change one of these default settings, you would copy the appropriate line from the default file to /boot/loader.conf, and make the change there.

75

For example, the first entry in the preceding listing is for the kernel filename, which we saw in our sysctl example earlier. Suppose you were working on a remote machine, and you wanted it to reboot the next time with a different kernel, but you didn't want to copy this other kernel to /kernel. You could change the kernel your system will use on boot by editing this one line. This is a sysctl that, obviously, can only be set at boot.

Let's look at two specific examples: passing hints to device drivers and automatically loading kernel modules.

Passing Hints to Device Drivers

Loader.conf's first purpose is to pass hints to device drivers. (If a device driver can use these hints, they're described in the manual page.)

As discussed earlier, the IDE hard drive's device driver must know if it should ask for write caching before booting the system. (This is documented in the ata(4) man page, and we will discuss write caching in Chapter 16.) To enable write caching, set the hw.ata.wc flag to 1 by entering the following in loader.conf:

...............................................................................................

hw.ata.wc="1"

...............................................................................................

That does it.

This type of flag should look familiar; it looks suspiciously like a sysctl MIB. In fact, once the system boots, check to see if it is a sysctl:

...............................................................................................

# sysctl hw.ata.wc

hw.ata.wc: 1

#

...............................................................................................

What do you know, it is!

When the system is running, you cannot change this sysctl. (Go ahead, try it, you won't hurt anything.) You changed a write−only sysctl by setting it at boot time. While this still won't help you turn that old Pentium into an Alpha, it does give you added flexibility.

Loading Kernel Modules Automatically

As I mentioned earlier, kernel modules are portions of a kernel that can be started (or loaded) when needed, and unloaded when unused. This feature can save system memory, and it improves system flexibility.

Loading a kernel module automatically at boot is fairly straightforward, and the default loader.conf offers many examples. To do so, copy the module name to loader.conf, cut off the trailing ".ko", and add the string _load="YES". For example, to load /module/procfs.ko automatically at boot, add the following to loader.conf:

76

...............................................................................................

procfs_load="YES"

...............................................................................................

The hard part, of course, is knowing which module to load. The easy ones are device drivers; if you add a new network or SCSI card, you can load the module at boot rather than rebuilding the kernel. If you're loading kernel modules to solve a particular system problem, you're probably doing this either from program documentation or someone's advice. Knowing which other modules to load comes with experience, reading documentation, and knowing what you want your system to do. I'll give specific pointers to certain kernel modules later.

Manually Configuring the Loader

If you're repeatedly rebooting to experiment with modules and sysctls, you probably don't want to keep editing /boot/loader.conf because it's just too time−intensive. Instead, adjust the loader manually at boot time. Then, once you find a configuration you like, you can alter /boot/loader.conf to your taste.

As discussed earlier, when your FreeBSD system first boots, it displays a 10−second countdown. If you hit a key and interrupt the countdown, you're brought to a loader command prompt—a simple command−line system where you can control initial system setup. You'll know you're in the loader when you see the loader prompt

................................................................

ok

................................................................

The loader is not UNIX—it's actually a small command interpreter written in Forth.[4] While a couple of loader commands resemble their UNIX counterparts, that's more for convenience than because of any underlying similarity.

Loader Commands

Entering a question mark (?) at the loader prompt will give you a very brief tutorial. Here are some of the most useful commands.

ls

The ls command lists files, just like in UNIX. It defaults to displaying the root directory; you can list another directory by giving the full path.

unload

Unload empties the system memory, which starts off containing the kernel and any modules specified in loader.conf.

load

The load command copies a file into memory. Use load to add kernel modules or even a new kernel. (You cannot load one kernel while another is still in memory though; you must unload the old

77

one first.)

For example, you could load the Intel EtherExpress network card driver like this:

................................................................

ok load /modules/if_fxp.ko

ok

................................................................

set

The set command allows you to set the value of a variable. For example, to test IDE write caching, you need to set hw.ata.wc to 1.

................................................................

ok set hw.ata.wc=1

ok

................................................................

[1]IPC is an acronym for interprocess communication, and various programs need this. Your program documentation will tell you if this sysctl needs to be altered.

[3]In more recent versions of FreeBSD, the −w is unnecessary; just give the assignment. [4]Forth is one of the very few programming languages that can fit in the tiny amount of space available in a computer's boot record. A similar program in C would require much more space. Every so often, someone volunteers to rewrite the boot loader in C, or BASIC, or some other language. These people are never heard from again.

Loading and Unloading Modules in Multi−User Mode

Some kernel modules don't need to be loaded in your system at boottime; they can be loaded and unloaded while the system is running. We'll look at how you can find out what modules you have in your system, then how to load and unload them.

Viewing Loaded Modules

Once your system is fully booted, you can see which kernel modules are loaded with kldstat(8):

................................................................

................................................................

In this listing, the laptop has two modules loaded: the kernel (kernel) and the Linux compatibility module (linux.ko, discussed in Chapter 10). Each module contains submodules, which you can view using kldstat −v, but be ready for a couple hundred lines of output.

78