-----BEGIN PGP SIGNED MESSAGE-----

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

> > Several people have pointed out how this is less flexible than NetBSD's
> > emulation layer...
> 
> Less flexible?  I do not see where did we loose flexibility at all.
> It has yet to be proven.  

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.

> > You yourself said, in your last post, that your method was ugly and
> > confusing to newcomers, but was chosen to complete the port more
> > quickly.  
> 
> I did not say ugly.  Nor confusing to newcomers.  

To quote you directly:

On Mon, 3 Nov 1997, Miguel de Icaza wrote:

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

So yes, you did say your implementation technique was ugly.  And
confusing to newcomers.

> It may be confusing for people trying to get a Linux-compat package
> ported from Intel to SPARC, but I do not see many people running into
> this problem, besides this effort.  Do you?

It also hampers development of driver or kernel code which can be
dropped into both ports.  NetBSD, by contrast can trivially share kernel
code, even device code between ports.  Why through this ability away for
no real gain (save perhaps a week or two of development time).

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

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

iQEVAwUBNF+Fnxg+dMhCouwfAQFFCwf9G8QjrcVsf/9MaB/JL1fQa2V9EmUVJ8ti
yYQq5FPTFG3XLy75hR5CNuxgJNNICA+zRSTXpFs/XKxN90LxcW2lMvPiSdSMti9O
fkIXl6Kr6VPe43Q2XvIHXloCnfWJN8dcsQD/P6LAqx2BEidkA6OO9sRkdt8msgT2
6XPaB4R/5mo8jl7gWt4hvkI0Bzh+BI2OV5mcrg8rJYSOttVTrWCOfeha5bRjrZm2
/5GxinXxBZolwcnB2qiMPf2vRPpMxaecxUngvTzFgYd5a5U0QFEpx4bJmAWrJCU3
7qS9uWLnJOB0/oUZK0NrnEdMfRtPg7L2qyOZZ3vvDsXB6aXQBl55xQ==
=yhHj
-----END PGP SIGNATURE-----