On 03 Nov 1997 19:04:30 -0600 
 Miguel de Icaza <miguel@luthien.nuclecu.unam.mx> wrote:

 > I am so glad to find that people liked our approach at doing this.

Hey, you took the bait!  :-)

 > Linux ports usually adapts themselves to the most common OS on the
 > target platform.  This way, we get emulation of the native binaries
 > for free in almost no time.

Matt Thomas and I exchanged several (on the order of 1 dozen or so, all
told) with Linus about this some time ago...

The idea was that Matt was looking for a sane way to determine the ABI
of a given ELF exectuable (which, thankfully, the binutils folks have
now done, using special .note sections, but I digress)...

Linus's response was something like:

	Naturally, since Linux is the most popular, you should
	simply adopt the Linux ABI.

To which we responded:

	WHICH ONE?!

...see below.

 > Just a couple of files here and there define what changes from machine
 > to machine, it is a pretty easy task to do.  
 > 
 > Sorry if this makes your life more complicated, but understand that
 > our goal was not to make the job of emulating Linux on the SPARC an
 > easy task; our goal was to have a userland up and running quickly.

Your argument of "gets the userland up and running quickly" doesn't
wash.  For one, it's not a native userland... you're talking about
using the userland from a different OS.  NetBSD was bootstrapped on
the Alpha using OSF/1 binaries.  4.4BSD (and, thus, NetBSD) was
bootstrapped using SunOS binaries.  So, I can totally understand the
motivation...

However, the implementation is, quite frankly, broken.  You see, simply
using the same constants and structure layouts as a different OS does
NOT give you binary compatibility with that OS.  You also have to
implement the semantics of the foreign system calls.  So, when I asked
Linus if each ports' system call semantics were different, too, he
of course said "No", which gave me the opportunity to assert that the
Linux approach for binary compatibility was broken.  There are other
reaons this is broken, too... For example, in the foreign system
call table, where do you place the personality(2) system call?
The answer, of course, is "you don't", because it's not in the
other system's system call table... but then you can't do what
every Linux executable needs to do - set the personality to Linux.
So, you're stuck doing something basically half-way for really no
benefit.

NetBSD does this whole thing with a thin emulation layer.  Native
executables run under the "netbsd" emulation.  Writing the compatibility
module is fairly straightforward.  Not much more difficult than duplicating
all those constants and structures, really.  And it saves the maintanence
nightmare of keeping all that duplicated information in synch.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-6                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939