This section describes how Linux binary compatibility
works and is based on an email written to FreeBSD chat mailing list by
<firstname.lastname@example.org> (Message ID:
FreeBSD has an abstraction called an “execution class loader”. This is a wedge into the execve(2) system call.
Historically, the UNIX loader examined the magic number (generally the first 4 or 8 bytes of the file) to see if it was a binary known to the system, and if so, invoked the binary loader.
If it was not the binary type for the system, the execve(2) call returned a failure, and the shell attempted to start executing it as shell commands. The assumption was a default of “whatever the current shell is”.
FreeBSD has a list of loaders, instead of a single loader, with
a fallback to the
#! loader for running shell
interpreters or shell scripts.
For the Linux ABI support, FreeBSD sees the magic number as an ELF binary. The ELF loader looks for a specialized brand, which is a comment section in the ELF image, and which is not present on SVR4/Solaris™ ELF binaries.
For Linux binaries to function, they must be
branded as type
brandelf -t Linux file
When the ELF loader sees the
brand, the loader replaces a pointer in the
proc structure. All system calls are indexed
through this pointer. In addition, the process is flagged for
special handling of the trap vector for the signal trampoline
code, and several other (minor) fix-ups that are handled by the
Linux kernel module.
The Linux system call vector contains, among other things,
a list of
sysent entries whose addresses
reside in the kernel module.
When a system call is called by the Linux binary, the trap
code dereferences the system call function pointer off the
proc structure, and gets the Linux, not the
FreeBSD, system call entry points.
Linux mode dynamically reroots
lookups. This is, in effect, equivalent to the
union option to file system mounts. First, an
attempt is made to lookup the file in
If that fails, the lookup is done in
This makes sure that binaries that require other binaries can
run. For example, the Linux toolchain can all run under
Linux ABI support. It also means that the
Linux binaries can load and execute FreeBSD binaries, if there
are no corresponding Linux binaries present, and that a
uname(1) command can be placed in the
/compat/linux directory tree to ensure that
the Linux binaries cannot tell they are not running on
In effect, there is a Linux kernel in the FreeBSD kernel. The various underlying functions that implement all of the services provided by the kernel are identical to both the FreeBSD system call table entries, and the Linux system call table entries: file system operations, virtual memory operations, signal delivery, and System V IPC. The only difference is that FreeBSD binaries get the FreeBSD glue functions, and Linux binaries get the Linux glue functions. The FreeBSD glue functions are statically linked into the kernel, and the Linux glue functions can be statically linked, or they can be accessed via a kernel module.
Technically, this is not really emulation, it is an ABI implementation. It is sometimes called “Linux emulation” because the implementation was done at a time when there was no other word to describe what was going on. Saying that FreeBSD ran Linux binaries was not true, since the code was not compiled in.