Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord)

[Farid Hajji]

> > might even introduce a security problem. Thus we would need to recompile
> > all programs anyway. I can't see the point of having binary
> > compatiblity then.
> 
> If a user just wants to play Quake V or Duke Nukem Forever, he might not
> need to care about PATH_MAX, as these programs will most likely only
> open trusted files.
> 
> Then again, if this is all he wants to do, some kind of binary
> compatibility layer might do the job just as well.  FreeBSD users claim
> to be quite happily running the GNU/Linux version of Quake III on their
> computers using compatibility libraries.

Quake III runs flawlessly on my FreeBSD 4.5-STABLE box. A lot of other
Linux-only binaries run too, like Maple, Oracle 8i, Java SDK 1.4.0 for
Linux, StarOffice 5.2, RealPlayer, etc... Some Linux binaries run even
_faster_ under FreeBSD than under Linux (e.g. setiathome client for Linux).
Go figure!

They are three aspects of BSD's Linux compatibility:

1. {Free,Open and Net}BSD provide Linux binary compatibility through a
simple trick: They just provide besides their normal ABI the Linux
ABI as well. When a Linux binary generates a syscall() and so a trap,
*BSD takes over and either handles the trap the BSD-way (most of Linux'
syscalls fall under this category) or the trap is redirected to a
Linux-specific kernel module which maintains enough state to implement
the Linux-specific things.

2. The BSD loader can recognize a Linux binary (if it is branded as
Linux ELF, else one can brand that binary manually with brandelf(1)).
Such binaries are then linked against the normal Linux dynamic libs
like glibc etc... Note that there is nothing special about the compat
libraries: they are just the normal Linux libraries. Users can replace
them or add their own linux libraries that would be used instead if
they wish. As soon as, say, glibc calls (linux) syscall(), the trap
handler in 1. takes over.

3. Linux' /proc filesystem differs from BSD's /proc fs. For this
reason, the BSD's implemented a subset of Linux' /proc (called
linprocfs) and mount it e.g. on /usr/compat/linux/proc. The linux
trap handler (more exactly, the VNODE layer) detects calls to /proc
from linux binaries and transparently redirects them to linprocfs.

The main advantage of BSD's Linux compatibility ABI is
  a. it exists ;-)
  b. it runs as fast as the native BSD ABI
     [actually, there is no such thing as a native and an emulated
      ABI in BSD. Both BSD and Linux ABIs are first-class citizens]

The main disadvantage of the current implementation of Linux compat
under BSD is
  c. it is still uncomplete [e.g. only subset of /proc in linprocfs,
     yet enough for most purposes, and some problems with specialized
     linux kernel modules (say ALSA...) that have no correspondent
     or mappable pendant in BSD].

There are other binary compatibility modes besides Linux. See NetBSD
http://www.netbsd.org/ for good examples of binary compat modes for
a lot of architectures ;)

All in all, binary compatibility is a nice thing to have.

> Oystein

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.