Kb107

Emulab FAQ: Software Setup: What FreeBSD kernels are available and what features do they include?

Emulab FAQ: Software Setup: What FreeBSD kernels are available and what features do they include?

Available Kernels (FreeBSD 4.10)

The FBSD-STD (aka FBSD410-STD) image has way too many special purpose kernels. Currently there is:

/kernel.100HZ. The default kernel, built to run with a 100HZ clock (100 clock interrupts per second). It is built from the sources in /share/freebsd/4.10/src/sys which is the standard FreeBSD 4.10 source with some local customizations. It is based on the GENERIC configuration, with many device drivers removed and the feature list modified slightly. The exact configuration is in /share/freebsd/4.10/src/sys/i386/conf/TESTBED. The significant features are: it is uniprocessor-only, has IPv6 and IPSEC support, has a larger than normal number of "mbufs" (network buffers), and includes support for the Linux ext2fs.
It also includes a couple of local features for better integration in the Emulab environment. ICMP_PINGOFDEATH is a feature to allow rebooting a machine with a special ICMP packet. MOUNTD_SUX_HACK is a "feature" intended to avoid a problem with the BSD NFS server which will briefly invalidate all exported filesystems when changing the export list.
This kernel should be sufficient for most uses.

/kernel.1000HZ also known as /kernel.linkdelay. The kernel used when you specify end-node shaping. It runs at a higher clock rate (1000HZ) to improve the accuracy of shaping. In addition to a higher clock rate, it also includes IPFW, dummynet, and divert socket support, necessary for traffic shaping. It also includes still more mbufs. The exact configuration is in /share/freebsd/4.10/src/sys/i386/conf/TESTBED-LINKDELAY.
You might want to use this kernel if you need firewall or dummynet support. See below for directions on how to setup your experiment to use this kernel.

/kernel.10000HZ also known as /kernel.delay. This kernel is used on the so-called "delay nodes", traffic shaping nodes. Since the nodes are dedicated to moving packets between interfaces, it is customized for that purpose: a high (10,000HZ) clock rate, use of polling (rather than interrupt-driven) device drivers, and still more mbufs. It includes the layer2 bridge code, in addition to the other options necessary for traffic shaping (firewall, dummynet, ipdivert). The exact configuration is in /share/freebsd/4.10/src/sys/i386/conf/TESTBED-DELAY.
You could use this kernel if you need a high clock rate, bridging, or polling device drivers. See below for customizing and using this kernel.

/kernel.jail. This is a highly specialized and non-standard kernel intended for use in our FreeBSD virtual node environment. It has support for multiple routing tables in addition to the other standard and linkdelay features. The exact configuration is in /share/freebsd/4.10/src/sys/i386/conf/TESTBED-JAIL.
You probably do not want to use this kernel for anything as the networking code is sufficiently different and we have not characterized its behavior versus a standard kernel.

Using an Alternate FreeBSD 4.10 Kernel

In order to use the above kernels as the default kernel in an experiment, you have to do a couple of things. First, you can only do this to a swapped in experiment. If you want to be able to specify using the kernel in future experiments, you will have to make the changes below, and then save a custom image.

Second, you need to fool the Emulab scripts into thinking this is the correct kernel to be running. If you want the delay kernel to be the standard you would need to:

as the Emulab scripts will double check that "/kernel.100HZ" is the same as "/kernel" and copy it and reboot if not. If you specified linkdelays in your NS file, then you will need to copy it to /kernel.1000HZ instead as that is the kernel that the scripts will attempt to make standard.

If you want to modify the clock rate of one of the standard kernels, you can modify /boot/loader.conf and add, for example:

kern.hz=1000 # for 1000HZ (1ms)

Going above 10,000 or below 100 is not advised.

Available Kernels (FreeBSD 6.x and beyond)

For FreeBSD 6 and beyond (i.e. FBSD64-STD, FBSD73-STD, FBSD81-STD),
there are now only two kernels to worry about:

/boot/kernel. This is the standard (now 1000HZ clock) kernel.
These are built from sources in '/share/freebsd/<version>/src/sys' using
the config in i386/conf/TESTBED (for 32-bit kernels) or amd64/conf/TESTBED
(for 64-bit kernels--please note that only the 'pc3000' and 'd710' node
types support 64-bit kernels!) These configs have the same extras as the
4.10 kernel described above (modulo vnode support, see below).
This kernel is used for "normal" as well
as "linkdelay" usage.

/boot/kernel.poll. This is the kernel used for delay nodes on
newer machines that do not support FreeBSD 4.10. It is build using the
same sources with the configs in {i386,amd64}/conf/TESTBED-POLLING.
As you may guess, the only difference is that it builds with support
for device polling (DEVICE_POLLING option). The kernel runs at 10000HZ
as specified by a boot-time command line option; i.e., it is no longer
hardwired in the kernel as in 4.10. IPFW, DummyNet and bridging are now
dynamically-loaded as needed and likewise are not hardwired in the kernel.

Note that there is no support for jail-based vnodes in newer FreeBSDs. This
may re-emerge in future FreeBSD 8 kernels which has standard support for multiple
network stacks.

Note also that in theory, we could have one kernel with DEVICE_POLLING
configured and either disabled or enabled, but we wanted to minimize difference
from the "stock" kernel for standard uses.

Using an Alternate FreeBSD 6 and beyond Kernel

Since there are only two kernels, this assumes that you want to use the
"polling" kernel as your default. (Note that there is no reason to do this
unless you need polling device drivers.)

As with 4.10, there are a couple of things to do.
First, you can only do this to a swapped in experiment.
If you want to be able to specify using the kernel in future experiments,
you will have to make the changes below,
and then save a custom image.

Second, you need to install the kernel where Emulab will expect to find it.
Unfortunately, the root filesystems on our FreeBSD installs is small, so you
need to be careful to not fill up that filesystem.