--- doc/en/books/handbook/linuxemu/chapter.sgml 2004/08/02 18:47:44 1.3 +++ doc/en/books/handbook/linuxemu/chapter.sgml 2005/06/27 23:49:01 1.4 @@ -190,10 +190,10 @@ Id Refs Address Size Name and the runtime linker. Also, you will need to create a shadow root directory, /compat/linux, for Linux libraries on your - FreeBSD system. Any shared libraries opened by Linux programs - run under FreeBSD will look in this tree first. So, if a Linux + &os; system. Any shared libraries opened by Linux programs + run under &os; will look in this tree first. So, if a Linux program loads, for example, /lib/libc.so, - FreeBSD will first try to open + &os; will first try to open /compat/linux/lib/libc.so, and if that does not exist, it will then try /lib/libc.so. Shared libraries should be installed in the shadow tree @@ -384,7 +384,7 @@ multi on The Linux version of &mathematica; runs perfectly under &os; however the binaries shipped by Wolfram need to be branded so that - FreeBSD knows to use the Linux ABI to execute them. + &os; knows to use the Linux ABI to execute them. The Linux version of &mathematica; or &mathematica; for Students can @@ -1226,7 +1226,7 @@ export PATH &sap.r3; System with &oracle; Database for Linux onto a &os; machine, including the installation - of FreeBSD and &oracle;. Two different + of &os; and &oracle;. Two different configurations will be described: @@ -1573,6 +1573,7 @@ export PATH Installation of FreeBSD + First you have to install FreeBSD. @@ -1729,7 +1730,7 @@ pam-0.68-7.i386.rpm relinking during &oracle; installation will not work). There are some other issues regarding relinking of &oracle;, but that is - a &oracle; Linux issue, not FreeBSD specific. + a &oracle; Linux issue, not &os; specific. @@ -3228,11 +3229,11 @@ options SHMMAXPGS=393216 How Does It Work? execution class loader - FreeBSD has an abstraction called an execution class + &os; has an abstraction called an execution class loader. This is a wedge into the &man.execve.2; system call. - What happens is that FreeBSD has a list of loaders, instead of + What happens is that &os; has a list of loaders, instead of a single loader with a fallback to the #! loader for running any shell interpreters or shell scripts. @@ -3253,14 +3254,15 @@ options SHMMAXPGS=393216 invoked the &man.csh.1; shell instead (we believe SCO first made this hack). - What FreeBSD does now is go through a list of loaders, with a + What &os; does now is go through a list of loaders, with a generic #! loader that knows about interpreters as the characters which follow to the next whitespace next to last, followed by a fallback to /bin/sh. ELF - For the Linux ABI support, FreeBSD sees the magic number as an + + For the Linux ABI support, &os; sees the magic number as an ELF binary (it makes no distinction between FreeBSD, &solaris;, Linux, or any other OS which has an ELF image type, at this point). @@ -3301,7 +3303,7 @@ options SHMMAXPGS=393216 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. + &os;, system call entry points. In addition, the Linux mode dynamically reroots lookups; this is, in effect, what the @@ -3315,19 +3317,19 @@ options SHMMAXPGS=393216 directory. This makes sure that binaries that require other binaries can run (e.g., 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 + load and execute &os; binaries, if there are no corresponding Linux binaries present, and that you could place a &man.uname.1; command in the /compat/linux directory tree to ensure that the Linux binaries could not tell they were not running on Linux. - In effect, there is a Linux kernel in the FreeBSD kernel; the + In effect, there is a Linux kernel in the &os; kernel; the various underlying functions that implement all of the services - provided by the kernel are identical to both the FreeBSD system + provided by the kernel are identical to both the &os; system call table entries, and the Linux system call table entries: file system operations, virtual memory operations, signal delivery, - System V IPC, etc… The only difference is that FreeBSD - binaries get the FreeBSD glue functions, and + System V IPC, etc… The only difference is that &os; + binaries get the &os; glue functions, and Linux binaries get the Linux glue functions (most older OS's only had their own glue functions: addresses of functions in a static global @@ -3336,10 +3338,10 @@ options SHMMAXPGS=393216 the proc structure of the process making the call). - Which one is the native FreeBSD ABI? It does not matter. + Which one is the native &os; ABI? It does not matter. Basically the only difference is that (currently; this could easily be changed in a future release, and probably will be after - this) the FreeBSD glue functions are + this) the &os; 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. @@ -3349,13 +3351,24 @@ options SHMMAXPGS=393216 simulator, to cut off the next question) involved. So why is it sometimes called Linux emulation? - To make it hard to sell FreeBSD! Really, it + To make it hard to sell &os;! Really, it is because the historical implementation was done at a time when there was really no word other than that to describe what was - going on; saying that FreeBSD ran Linux binaries was not true, if + going on; saying that FreeBSD + + + FreeBSD + + FreeBSD's original Linux compatibility code was + committed in June 1995. It fulfilled milestone number one: + running DOOM. + + ran Linux binaries was not true, if you did not compile the code in or load a module, and there needed to be a word to describe what was being loaded—hence the Linux emulator. + +