The evolution of FreeBSD

FreeBSD has been around for ten years. During this time, it has evolved significantly, and it continues to evolve. In this chapter we'll look at what has changed, particularly in more recent times. If you're planning to install one of the older releases of FreeBSD, for example on old hardware that is too small for modern releases, refer to Appendix A, Bibliography, for copies of older editions of this book.

FreeBSD Releases 1 and 2

Release 1.0 of FreeBSD appeared in December 1993. It was substantially an improved and debugged version of 386/BSD, based on the 4.3BSD Net/2 tape. FreeBSD Release 2 was released in January 1995. The big difference from Release 1 was that it was based on 4.4 BSD Lite, one of the results of the lawsuit we discussed on page 8. There were no major differences from Release 1.

FreeBSD Release 3

FreeBSD Release 3.0 was released in September 1998. It represented the biggest change in FreeBSD since the code base was moved to 4.4BSD. A number of new features were introduced, which made upgrading a little more complicated than is normally the case. In particular, the following new features were of note:

The CAM SCSI driver

FreeBSD Release 3.0 included a new SCSI driver, based on the ANSI ratified Common Access Method or CAM specification, which defines a software interface for talking to SCSI and ATAPI devices. The FreeBSD driver is not completely CAM compliant, but it follows many of the precepts of CAM. More importantly, it addresses many of the short comings of the previous SCSI layer and provides better performance and reliability, and eases the task of adding support for new controllers.

For most users, the most obvious difference between the old SCSI driver and CAM is the way they named SCSI devices. In the old driver, disks were called sdn, and tapes were called stn, where n was a small positive number. The CAM driver calls disks dan (for direct access), and tapes are called san (for serial access).

In addition, a new program, camcontrol, enables you to administrate the SCSI chain at a more detailed level then previously: for example, it is now possible to add devices to a chain after the system has started. See the man page for more details.

Kernel loadable modules

Older releases of FreeBSD supplied Loadable Kernel Modules or LKMs, object files that could be loaded and executed in the kernel while the kernel was running.

The ELF kernel and the new bootstrap introduced with FreeBSD Release 3 allow you to load additional modules at boot time. To do so, however, the format of the modules needed to be changed. To avoid (too much) confusion, the name changed from loadable kernel module to kernel loadable module (kld).

Some other details have changed as well. kldload knows an internal path for finding klds, so you don't need to specify the path unless it's in a non-standard location. It also assumes that the name of the kld ends in .ko, and you don't need to specify that either. For example, to load the Linux emulator as an LKM, you entered:

# modload /lkm/linux_mod.o

To load the kld, you enter:

# kldload linux

kldload searches for klds in a number of places. Table B-1 shows the default path, /boot/kernel. If you boot from a different kernel, for example /boot/kernel.old/kernel, the path will change to /boot/kernel.old. Up to Release 4 of FreeBSD, it searched /modules as well. At the time of writing, this directory is still in the search path, but it may be phased out. It's a bad idea to store kernel code where it might be loaded by different kernels.

The ELF object format

When UNIX was written, the world was simple. The kernel of the Third Edition of UNIX, in January 1973, had a little over 7,000 lines of code in total. The FreeBSD 5.0 kernel has approximately 300 times as much code. The original UNIX object format was correspondingly simple: it had provision for only three data segments. It was named after the name of the output from the assembler, a.out.

In the course of time, binaries required additional features, in particular the ability to link to dynamic libraries. UNIX System V introduced a new object file format, COFF, but BSD objected to some of the details of COFF and remained with a.out and used some rather dirty tricks to link to dynamic libraries. The change to ELF enabled a much cleaner interface.

Since Release 3, FreeBSD uses ELF as the default executable format, but the Intel port supported execution of a.out binaries until Release 5. The Alpha port was created after the change to ELF and does not support a.out at all.

What happened to my libraries?

One detail of the change from a.out to ELF can make life difficult: ELF and a.out executables need different libraries, each with their own format, but frequently with the same name. For example, the system now knows the following versions of the standard C library, which is required by every program:

Don't worry if these names don't make much sense to you; unless you're writing programs, all you need to know is that an ELF system uses /usr/lib/libc.so at run time.

/usr/lib contains a large number of libraries. It would be possible, but messy, to find an alternative arrangement for the name contacts, and leave the rest of the names unchanged. Instead, the conversion process move sall a.out libraries to a subdirectory aout, so an a.out executable now looks for /usr/lib/aout/libc.so.3.0. An ELF executable looks for /usr/lib/libc.so.3.

But how does the system know to look in a different place? It uses a hints file generated by the ldconfig program. When the system starts, it takes a list of directory names from /etc/rc.conf and runs ldconfig to search the directories for a.out libraries and to generate the hints file. In Release 2 of FreeBSD, the standard /etc/rc.conf contained the following definition:

ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/local/lib"
       # search paths

In Release 3.0, this changed to:

ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/local/lib"
       #shared library search paths 
ldconfig_paths_aout="/usr/lib/compat/aout /usr/X11R6/lib/aout /usr/local/lib/aout"
       #a.out shared library search paths

Upgrading from Release 2 of FreeBSD

If you're still using Release 2, you might run into some minor problems. The following discussion applies when upgrading to Release 3 or anylater release: part of the upgrade process from Release 2 to Release 3 changes this entry in /etc/rc.conf so there should be no problem with normal libraries. A couple of problems may still occur, however:

/usr/lib/compat:
total 1
-r--r--r--  1  root  wheel  8417  Jan 21 18:37  libgnumalloc.so.2.0
-r--r--r--  1  root  wheel  8398  Jan 21 18:37  libresolv.so.2.0
lrwxr-xr-x  1  root  wheel    31  Jan 21 18:36  libtermcap.so.3.0 -> /usr/lib/libte
rmcap.so.2.1
lrwxr-xr-x  1  root  wheel    31  Jan 21 18:36  libtermlib.so.3.0 -> /usr/lib/libte
rmlib.so.2.1
-r--r--r--  1  root  wheel  8437  Jan 21 18:37  liby.so.2.0

/usr/lib/compat/aout:
total 1
-r--r--r--  1  root  wheel  8417  Jan 21 18:37  libgnumalloc.so.2.0
-r--r--r--  1  root  wheel  8398  Jan 21 18:37  libresolv.so.2.0
lrwxr-xr-x  1  root  wheel    31  Jan 21 18:36  libtermcap.so.3.0 -> /usr/lib/libte
rmcap.so.2.1
lrwxr-xr-x  1  root  wheel    31  Jan 21 18:36  libtermlib.so.3.0 -> /usr/lib/libte
rmlib.so.2.1
-r--r--r--  1  root  wheel  8437  Jan 21 18:37  liby.so.2.0

cd /usr/lib/compat/aout
rm libtermcap.so.3.0
ln -s libtermcap.so.2.1 libtermcap.so.3.0
rm libtermlib.so.3.0
ln -s libtermlib.so.2.1 libtermlib.so.3.0

# cd /usr/X11R6/lib
# mkdir aout
# cp -p lib* aout

FreeBSD Version 4

FreeBSD Release 4.0 appeared in March 2000. It included a number of significant changes from Release 3. At the time of writing, FreeBSD Release 4 is still a current release, in parallel with Release 5.

First, the good news: the differences between Release 3 and Release 4 aren't as far-reaching or as complicated as the differences between Release 2 and Release 3. Still, there are a couple of things that you need to know. There are also a few things that make installation easier. You can get a blow-by-blow description of the changes from the file /usr/src/UPDATING. This document discusses the following more important new features:

NO_OPENSSH=yes

No more block devices

From the beginnings of UNIX, users were confused by the fact that a disk drive could appear in two different ways, either a blockdevice or a character device, also called a raw disk. For example, your root partition might have been one of these:

$ ls -l /dev/wd0a /dev/rwd0a
crw-r  1  root   operator   3,   0 Oct 19   1997 /dev/rwd0a
brw-r  1  root   operator   0,   0 Oct 19   1997 /dev/wd0a

Araw device always accesses the drive directly. As a result, you're limited to the way the drive is organized: the transfer must start on a sectorData on disk used to be stored in units called sectors.Modern disks store data in a number of different ways, butthis is not visible outside the drive.The externally visible unit of data is still a sector of 512 bytes boundary and must be an integral number of sectors long. By contrast, block devices are buffered: instead of accessing the disk directly, the system transfers data via an area of memory called buffer cache. You access the copyofthe data in buffer cache. This has the advantages that you can access it much more quickly if it is in cache, and you don't have to pay any attention to sector boundaries. Still, having two different kinds of device is confusing, and it's obvious why we should want to simplify things.

But why are block devices going away, and not the rawdisks? Until recently, for example, Linux didn'thave any raw disk access, only block devices. There are a number of reasons to prefer to keep the rawdisks:

If you want to access disks in an aligned fashion, it's faster: you don'thave to go via buffer cache. This also saves memory.

If you have an error on a write to a raw device, you get an error indication immediately.On a block device, the error may not occur until after the process has terminated, too late to try to recover.

The buffer cache isn't going away, only the device interface. It's very seldom that you'll find a need to access disk devices directly from user context. The most common access is via a file system or as swap. In the former case, the file system provides the buffering, and in the latter case it's counter productive, since swap always writes entire pages. The only other access to disk devices is from system programs like disklabel, newfs and mount, all of which have always accessed the raw device.

For most users, the biggest difference is that you will neveruse a name like /dev/rda0a again; instead, it will become /dev/da0a. If you are upgrading, you must run /dev/MAKEDEV to recreate the device nodes.

Note that in Release 5 of FreeBSD, /dev/MAKEDEV is no longer needed.

New ATA (IDE) disk driver

There is a new driver, ata, for ATA (AT attachment) drives, which were formerly called IDE. It supports not only disks but also ATAPI CD-ROM and DVD drives, ZIP drives and tape streamers.

In the process, the name of the devices has changed: disk drives are now called ad,CD-ROM drives are called acd, LS-120 floppies are called afd, and tapes are called ast.

For a transition period, the wd driver remains available, but you shouldn't use it unless you have very good reasons, for example if you have old or unusual hardware that has trouble with the ad driver.

New console driver

FreeBSD Release 4 includes a new console driver. The configuration file entries have changed. See the GENERIC configuration file for more details.

FreeBSD Release 5

FreeBSD Release 5 is the latest release of FreeBSD. It has a number of new features, most of which are transparent to the user. There's a complete list in the release notes, which you should certainly read if you're upgrading the system, but here are some highlights:

SMP (symmetric multiprocessor) support has been rewritten from scratch. This will ultimately give much better performance and scalability,though currently the performance potential has not been fully realized. We looked at some of the visible differences on page 148.

The kqueue event notification facility is a newinterface that is able to replace poll and select. It offers improved performance as well as the ability to report many different types of events. Support for monitoring changes in sockets, pipes, fifos, and files are present, as well as for signals and processes.

A large number of kernel configuration options have been turned into boot-time tunable variables, and the need to build specific kernels has become much more seldom.

The Kernel-Scheduled Entity (KSE) project offers multi-threading in the kernel.

Support for the 80386 processor has been removed from the GENERIC kernel, as this code seriously pessimizes performance on other IA32 processors.

The I386_CPU kernel option to support the 80386 processor is now mutually exclusive with support for other IA32 processors; this should slightly improve performance on the 80386 due to the elimination of run time processor type checks.

Custom kernels that will run on the 80386 can still be built by changing the cpu options in the kernel configuration file to only include I386_CPU.

Support has been added for 64 bit SPARC and IA 64 (Itanium) processors.

The system includes the device file system, or dev/s. In older releases of FreeBSD, as in other versions of UNIX, the directory /dev contained device nodes, entries that looked like files but which in fact described a possible device on the system. The problem was that there was no good way to keep the device nodes in sync with the kernel, and problems occurred where the hardware corresponding to a device node didn't exist (a "Device not configured" error), or where the device node corresponding to the hardware did not exist (a "no such file or directory" error). devfs solves this problem by creating at boot time the device nodes for the hardware the system finds.

The disk I/O access system has been rearranged and made more flexible with the GEOM framework.

A number of file system enhancements have been made. The standard UFS file system now supports snapshots and background file system checking after a crash, significantly reducing reboot time after a crash.

UFS has been significantly enhanced as UFS2. It supports files larger than 1 TB and extended file attributes.

The PCMCIA code has been rewritten and now supports CardBus devices.

The default kernel no longer supports a.out file format. You can still execute these files by loading the aout.ko KLD.

FreeBSD now supports the Advanced Configuration and Power Interface (ACPI), the replacement for APM.

It is now possible to increase the size of ufs file systems with the growfs command.

Vinum now supports the root file system. See Chapter 12 for details.