16.1 FreeBSD and Tru64

Tru64 and FreeBSD use an almost identical process for building a customized kernel. They rely on a configuration file for specifying which capabilities to include within the kernel and setting the values of various system parameters. The configuration file is located in /usr/sys/conf on Tru64 systems and in /usr/src/sys/arch/conf under FreeBSD, where arch is an architecture-specific subdirectory (we'll use i386 as an example).

Configuration filenames are conventionally all uppercase, and the directory typically contains several different configuration files. The one used to build the current kernel is usually indicated in the /etc/motd file. For example, the GENERIC file was used to build the kernel on this FreeBSD system:

FreeBSD 4.3-RELEASE (GENERIC) #0: Sat Apr 21 10:54:49 GMT 2001

Default Tru64 configuration files are often named GENERIC or sometimes ALPHA.

On FreeBSD systems, you will first need to install the kernel sources if you have not already done so:

FreeBSD # cd / # mkdir -p /usr/src/sys       If not already present. # mount /cdrom # cat /cdrom/src/ssys.[a-d]* | tar xzvf -

To add a device to a Tru64 system, you must boot the generic kernel, /genvmunix, to force the system to recognize and create configuration information for the new device:

Tru64 # shutdown -r now ... >>> boot -fi /genvmunix ... # bcheckrc or lsmbstartup # sizer -n NEWDEVS

On both systems, the first step in configuring and building a kernel is to save a copy of the old configuration file and then make any necessary changes to it:

FreeBSD	Tru64
# cd /usr/src/sys/i386/conf # cp GENERIC NEWKERN # chmod +w NEWKERN # emacs NEWKERN	# cd /usr/sys/conf # cp GENERIC NEWKERN # chmod +w NEWKERN # emacs NEWKERN [/tmp/NEWDEVS]

The GENERIC configuration file is the standard, hardware-independent version provided with the operating system. If you have already customized the kernel, you would start with the corresponding configuration file instead.

While editing the new configuration file, add (or activate) lines for new devices or features, disable or comment out lines for services you don't want to include, and specify the values for any applicable kernel parameters. In general, it's unlikely that you'll need to modify the contents of hardware device-related entries. The one exception is the ident entry, which assigns a name to the configuration. You should change it so its value corresponds to the name you have selected:

ident NEWKERN

You may also occasionally remove unneeded subsystems by commenting out the corresponding option's entry, as in this example, which disables disk quotas:

#options QUOTA     Tru64

On Tru64 systems, you will need to merge in any new device lines from the file created by the sizer command (placed into /tmp), indicated by the optional second parameter to the Tru64 emacs command above. One way to locate these device lines is to diff that file against your current kernel configuration file or the GENERIC file.

The FreeBSD configuration file contains a large number of settings, most of them corresponding to hardware devices and their characteristics. In addition, there are several entries specifying the values of various kernel parameters that might need to be altered in some circumstances. For example:

FreeBSD options   MAXCONS=4 options   MAXDSIZ="(256*1024*1024)" device          usb                     USB device support. device          ugen device          ohci device          uhci device          uhid                    Human interface support (needed for mouse). device          ums                     USB mouse.

These entries specify the maximum number of virtual consoles and the maximum individual process address space and also select support for a USB mouse. (Note that these lines come from various points in the configuration file.)^[3]

^[3] Many kernel parameters can also be modified via the sysctl command and its initialization file (see Section 15.4).

You can examine the LINT or NOTES configuration file for documentation on most available parameters.

The next step in the kernel build process is to run the command that creates a custom build area for the new configuration:

FreeBSD	Tru64
# config NEWKERN # cd ../../compile/NEWKERN # make depend # make # mv /kernel /kernel.save # make install	# doconfig -c NEWKERN # cd ../NEWKERN # make depend # make vmunix # mv /vmunix /vmunix.save # cp ./vmunix /

doconfig and config create the NEWKERN subdirectory, where the new kernel is actually built. Once the make commands complete, the new kernel may be installed in the root directory and tested.

If there are problems building the new kernel, you can boot the saved version with these commands:

FreeBSD	Tru64
disk1s1a:> unload disk1s1a:> load kernel.save disk1s1a:> boot	>>> boot -fi vmunix.save

16.1.1 Changing FreeBSD Kernel Parameters

FreeBSD also allows manykernel parameters to be changed dynamically. The sysctl command can be used to list all kernel parameters along with their current values:

# sysctl -a kern.ostype: FreeBSD kern.osrelease: 4.3-RELEASE kern.osrevision: 199506 kern.maxvnodes: 6322 kern.maxproc: 532 kern.maxfiles: 1066 ...

The sysctl manual page indicates which parameters may be modified.

You can use this command form to modify a parameter value:

# sysctl kern.maxfiles=1066 kern.maxfiles: 1064 -> 1066

Such changes do not persist across boots, so they must be repeated each time your system starts. You can also place the desired settings the string given to -w into the file /etc/sysctl.conf to have them automatically applied at boot time. Alternatively, you can rebuild the kernel after setting the corresponding options in the kernel configuration files.

16.1.2 FreeBSD Kernel Modules

FreeBSD also provides support for kernel modules; you can compile them via the corresponding subdirectories in /usr/src/sys/modules. The kldstat -v command displays a list of currently-loaded kernel modules. Virtually all are used for supporting devices or filesystem types. You can load and unload kernel modules manually with the kldload and kldunload commands.

The file /boot/loader.conf specifies modules that should be loaded at boot time:

userconfig_script_load="YES"     Line created by sysinstall. usb_load="YES"                   Load USB modules. ums_load="YES" umass_load="YES"

Of course, you need to create the required modules before they can be autoloaded.

16.1.3 Installing the FreeBSD Boot Loader

Generally, the FreeBSDboot loader is installed by default in the Master Boot Record (MBR) of the system disk. However, should you ever need to, you can install it manually with this command:

# boot0cfg -B /dev/ad0

The -B option says to leave the partition table unaltered.

You can also use this command's -m option to prevent certain partitions from appearing in the boot menu. This option takes a hexadecimal integer as its argument. The value is interpreted as a bit mask that includes (bit is on) or excludes (bit is off) each partition from the menu (provided that it is a BSD partition in the first place). The ones bit in the mask corresponds to the first partition, and so on.

For example, the following command enables only partition 3 to be listed in the menu:

# boot0cfg -B -m 0x4 /dev/ad0

The disklabel -B command can be used to install the boot program into the boot portion of a FreeBSD subpartition within a physical disk partition, as in this example, which installs the boot program into the first subpartition in the first partition:

# disklabel -B /dev/ad0s1

16.1.4 Tru64 Dynamic Kernel Configuration

Tru64 also supports two sorts of kernel reconfigurationwithout needing to build a new kernel: subsystem loading and unloading and kernel parameter modifications.

A very few subsystems may be dynamically loaded and unloaded into the Tru64 kernel. You can list all configured subsystems using the sysconfig command:

# sysconfig -s cm: loaded and configured hs: loaded and configured ksm: loaded and configured ...

Subsystems can be loaded or unloaded. The -m option displays whether each one is dynamic (loadable and unloadable with a running kernel) or static:

# sysconfig -m | grep dynamic hwautoconfig: dynamic envmon: dynamic lat: dynamic

On this system, only three subsystems are dynamic. For these modules, you can use the sysconfig -c and -u options to load and unload them, respectively.

Static and dynamic subsystems can also have settable kernel parameters associated with them. You can view the list of available parameters with a command like this one:

# sysconfig -Q lsm     Parameters for the Logical Storage Manager lsm: Module_Name -            type=STRING op=Q min_len=3 max_len=30 lsm_rootdev_is_volume -  type=INT op=CQ min_val=0 max_val=2 Enable_LSM_Stats -       type=INT op=CRQ min_val=0 max_val=1

The display lists the parameter name, its data type, allowed operations, and valid range of values. The operations are specified via a series of code letters: Q means can be queried, C means the change occurs after reboot, R means the change occurs on a running system.

In our example, the first parameter (the name of the module) can be queried but not modified; the second parameter (whether the root filesystem is a logical volume) can be modified, but the new value won't take effect until the system reboots; and the third parameter (whether subsystem statistics are recorded) takes effect as soon as it is changed.

You use the -q option to display the current value of a parameter and the -r option to change its value:

# sysconfig -q lsm Enable_LSM_Stats lsm: Enable_LSM_Stats = 0 # sysconfig -r lsm Enable_LSM_Stats=1 Enable_LSM_Stats: reconfigured

The /etc/sysconfigtab file can be used to set kernel parameters at boot time (see Section 15.4).

If you prefer a graphical interface, the dxkerneltuner utility can also be used to view and modify the values of kernel parameters. The sys_attrs manual page provides descriptions of kernel parameters and their meanings.