>  > 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.  

Ok, I made a mistake.  Indeed, it does not get you a userland quickly,
but it lets you use the system quickly.  And get a self hosting system
quickly (which was the case) and on the end, you get the binary
emulation for the popular OS on your architecture for free.

> 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.  

This is correct.  But it gets you there fast.  And that was the case
with Linux/SPARC.  

> 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.

I do not quite understand what you mean. 

When the semantics of a system call are different from Linux and from
the other OS, you just use different entry points for those system
calls.  Look at our sunos emulation wrappers, they are a very small
set of routines.   

> 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... 

I do not understand your concern here, but probably your concern comes
from a mistake we did when the SPARC port was done: we used the same
system calls as SunOS, even if we had different system call tables for
Linux and SunOS.  

So, we just lost some time on that, but this does not affect the
assignement of system calls at all.  if we need a new system call, we
just go and add that to the Linux-only system call table.  

> but then you can't do what every Linux executable needs to do - set
> the personality to Linux.  

This is not used at all on the Linux/SPARC port.  That is an intelism
that we did not bring to the SPARC since we do not need it.  And even
if we required it, this can be easily implemented without any problem
as I outlined above. 

> So, you're stuck doing something basically half-way for really no
> benefit.

Well, it is just a matter of having system call that are numbered in a
different way.  I do not really think this poses any real problem
(besides the fact that it looks a ugly and may confuse newcomers to
the kernel). 

best wishes,
Miguel.
-- 
miguel@kernel.org