Subject: Re: Linux emulation for SPARC?
To: Miguel de Icaza <miguel@nuclecu.unam.mx>
From: Jim Wise <jimw@numenor.turner.com>
List: port-sparc
Date: 11/04/1997 15:55:30
-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 4 Nov 1997, Miguel de Icaza wrote:

> > Simple.  By having a central dispatch point for emulation type, NetBSD
> > can not only easily support multiple emulations per platform, but can
> > provide emulations easily after the fact, even in an LKM.  All while
> > keeping the NetBSD execution environment identical between ports.
> 
> This can be done as well with Linux.  Your point?

Maybe it could have been done, but it isn't.  Again, so it's clear:
NetBSD keeps an identical execution environment between ports, and
provides a more modular emulation implementation.  Linux does not.  (It
uses different structure layouts, syscall numbers, and errno values, and
it depends on these different values in order to be able to implement
emuation.)

> > So yes, you did say your implementation technique was ugly.  And
> > confusing to newcomers.
> 
> Ok, you are right.  Let me correct myself: I intended to mean
> newcomers that are planning to write an emulation layer for their
> favorite OS.  

So it's not confusing to newcomers that when I move my kernel code from
Linux to SparcLinux, I need to repad my structs and rearrange my syscall
number usage?

> > It also hampers development of driver or kernel code which can be
> > dropped into both ports.  
> 
> This has never stopped Linux from sharing kernel code or device
> drivers between ports.  

No, but it certainly does make it more work, as that code has to be
edited to make it work on each port.  By comparison, huge parts of
NetBSD's kernel _and_driver_ code are platform independent, and are
quite literally shared between all ports which use that device.  This
also makes it possible to build all ports out of the same source tree,
BTW.

> If Linux does not share more code between its drivers, it may be due
> to other reasons.  The way Linux was adapted to a particular port has
> *NEVER* been a reason to stop sharing code.  

No, but it certainly does seem to make it harder...

- --
				Jim Wise
				jim.wise@turner.com

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQEVAwUBNF+Lxxg+dMhCouwfAQEa3wgAhd061AKGCdcnUtzC7QFD1Sj3ONHNQt7z
fU5Ct9+V4aAx7qJxjUQ8ll6NOJ4bC3WoGEJA7dlTS+08lYdPeDxUjhKYhaZQVzm0
1pRG9ZziYo96mkjZjtFDaH8fmiWoPp37bpMpH5cQnhL4skN8TMtyAb7KPKn8Y1uz
dj5PKksFhw4HUhuunUy1j8JIILF/CjkmXyeN9+AgMars1tqXZNvuC3QLAD8na0Si
9sgBWAdFABrgeCHqBO3ZqwcIvqQkiCQN0nFJSoCQHdpJnpV5zLQspgQ3BDl9ZCzE
aGUTfUGhICrgs9LAU2FkhQRgrh/xIXokNebqkGMU8fl58Vx4totUiQ==
=xuyE
-----END PGP SIGNATURE-----