[1]If you're reading this book, you're probably the systems administrator. But you'll need this as a solution for your users.

Running Software from the Wrong OS

Traditionally, operating systems have had to have software written for them, and a piece of software would only run on the platform it was designed for. That said, many people have built a healthy business by changing software for one platform so it will run on another system, a process called porting.

As an administrator, you can use software written for a platform other than FreeBSD in a few different ways. The most effective way is to recompile the source code to run natively on FreeBSD. Alternatively, and barring your recompiling a program, you can also run non−native software under an emulator, or by re−implementing the application binary interface (ABI) of the native platform.

Recompilation

Many pieces of software in the ports collection are actually native recompiles of software originally designed for other platforms, such as KDE and Emacs. In fact, software written for Linux, Solaris, or other UNIX variants can frequently be built (recompiled) from source code with little or no modification to run without a hitch on FreeBSD. By simply taking the source code and building it on a FreeBSD machine, you can run foreign software natively on FreeBSD.

Recompiling works best when the platforms are similar. For example, FreeBSD and Linux provide many identical system functions: both are built on the standard C functions, as defined by POSIX, and both use similar building tools and have mostly identical system calls.

However, over the years, the various UNIX platforms have diverged. Each version of UNIX has implemented new features that require new libraries and functions, and if a piece of software requires those functions, it won't build on other platforms.

The POSIX standard was introduced, in part, to alleviate this problem. POSIX is a standard that defines minimal acceptable UNIX and UNIX−like operating systems. Software written using only POSIX−compliant system calls and libraries should be immediately portable to any other operating system that implements POSIX, and most UNIX vendors comply with POSIX.

The problem is ensuring that developers comply with POSIX. Many opensource developers care only about having their software run on their preferred platform. For example, there's a lot of software out there that is Linux−specific, but not POSIX−compliant. And POSIX−only code does not take advantage of any special features offered by the operating system.

For example, FreeBSD has the hyper−efficient data−reading system call kqueue(2). Other systems use select(2) and poll(2) instead. The question developers need to ask themselves is whether they should use kqueue, which would make their software blindingly fast on FreeBSD and unable to work on anything else, or whether they should they use select and poll, allowing their software to run more slowly but on more platforms. The developer can invest more time in setting up the software to use different functions on different platforms; but while this would make users happy, it rather sucks from the developer's point of view. Whatever the developer's choice, someone will complain.

The FreeBSD Project takes a middle road. If a piece of software can be compiled and run properly on FreeBSD, the ports team generally makes it happen. If the software needs minor patches, the

256

ports team includes the patches with the port and sends the patches back to the software's developer. Most software developers gladly accept patches that allow them to support another operating system. Even though they might not have that OS available to test on, or they might not be familiar with the OS, if a decent−looking patch arrives from a reputable source, they probably won't turn it down.

Emulation

If software would require extensive redesign to support FreeBSD, or if source code is simply not available, we need to turn to another option: emulation. The concept of an emulator is simple. An emulator program translates system calls for one operating system to the system calls used by the local operating system, and programs running under the emulator think they're running on their native system. Translating these system calls does create additional system overhead, though, which takes its toll on the speed with which programs run under the emulator.

FreeBSD supports a wide variety of emulators, most of which are in the ports collection under /usr/ports/emulators. In most cases, emulators are useful for education or entertainment. If you have an old Commodore 64 game that you've had an insatiable desire to play again, you can install /usr/ports/emulators/frodo. (You can also learn more about disks than you ever wanted to know by trying to get that C64 floppy to work with UNIX, but that's a separate matter.) To see what classic UNIX hardware looks like, you can install the PDP−11 emulator under /usr/ports/emulators/sim. (For a complete list, see /usr/ports/emulators/README.html.)

However, since these emulators are not really useful for server operations, we won't cover them in depth. You should know that they're available, though, and where to find them.

ABI Implementation

In addition to recompiling and emulating, the final option for running foreign programs is the one FreeBSD is best known for: ABI (application binary interface) implementation. The ABI is the part of the kernel that provides services to programs, including everything from sound−card access to reading files to printing on the screen to starting other programs—all the things a program needs to run. As far as programs are concerned, the ABI is the operating system. By completely implementing the ABI from a different operating system on your operating system, you can run non−native programs as if they were on the native platform.

While ABI implementation is frequently referred to as "emulation," it isn't really. When implementing ABIs, FreeBSD is not emulating the system calls, but providing them natively. By the same token, it would be incorrect to say that "FreeBSD implements Linux" or "FreeBSD implements Solaris." The fact is, when this technique was created, there was no one word to describe what the BSD team was doing. (Even today, there's no one word to describe it. How's that for bleeding−edge work?) You'll most often hear it referred to as a mode, such as "Linux mode" or "osf1 mode."

The problem with emulating the ABI is overlap. Most operating systems include system calls with generic names such as read, write, and so on. The read system call on a FreeBSD system behaves very differently from the read found on a Windows system. If you re−implement every single foreign system call in your OS, you've just made your operating system a re−implementation of the foreign OS. When a program calls read, how would it know if it was getting the native or foreign version? You can give your system calls different names, but then you're violating POSIX. Or you can provide multiple ABIs and control which ABI a program uses. This is what FreeBSD does.

257

Binary Branding

Operating systems generally have a straightforward system function that executes programs: Whenever the kernel sends a program to the execution engine, the execution engine runs the program.

At some point, however, the UNIX program execution system was hacked to include a special check for programs that began with #!/bin/sh, and to run them with the system shell instead of the execution engine. BSD took this idea to the logical extreme, and its execution engine includes a list of different binary types. Each program's binary type directs it to the correct ABI. Thus, a BSD system can have multiple ABIs, and can support programs from a variety of different operating systems.

The nifty thing about this system of redirects is that there's no overhead: Since the system decides how to run the program anyway, why not have it decide which ABI to use? After all, binaries for different operating systems all have slightly different characteristics, which are used to identify them; this system simply makes the process transparent to the end user.

As a result of this ABI redirection, FreeBSD can run Linux, OSF/1, System V, and SCO binaries as if they were compiled natively, thus vastly expanding the range of software available for use on FreeBSD.

Note FreeBSD supports this range of ABIs for two reasons. First, someone with the skill to implement it needed it. Second, the documentation was available. The implemented ABIs are all very similar to FreeBSDs; only a few system calls require extensive development.

Which ABIs Are Supported?

This scheme makes it entirely possible to implement extremely foreign ABIs. For example, someone could take Windows ABI information from Microsoft and write a Windows ABI module for FreeBSD, which would allow FreeBSD to run Windows programs natively. While this would be pretty darn cool, it would also be a fiendish amount of work to implement in a stable and reliable manner. It hasn't been done, and isn't likely to happen. The three modes that are most supported are SVR4, OSF/1, and Linux.

SVR4, or System V Release 4, was the last major release of UNIX from AT&T. It appears in early versions of Solaris and SCO UNIX. Some SCO software is reported to perform more quickly and reliably in FreeBSD's SVR4 mode than it does on actual SCO UNIX.

OSF/1, or Digital UNIX, was designed for the Alpha processor. Digital first built the Alpha CPU and created Digital OSF/1 to run on it. Because OSF/1 used a Mach kernel, and FreeBSD doesn't include the various non−POSIX system calls that were part of Mach, FreeBSD's OSF/1 mode is incomplete. In any event, it won't run on Intel−compatible hardware. (Implementing a foreign ABI is difficult enough without providing 64−bit instructions on 32−bit hardware!) Now, chances are, you don't have an Alpha, so we aren't going to discuss it in any depth.[2]

Finally, Linux mode allows FreeBSD to run Linux software. This ABI has been the most thoroughly tested because the source code for Linux is available and its ABI is well documented. In fact, the Linux mode works so well that many programs in the ports collection rely upon it. (Chunks of this book were written on StarOffice 5.2 under Linux mode, and I've used Linux Netscape and even Linux WordPerfect without problem.)

258