On Mon, 20 Jan 1997 20:49:28 +1100 (EST), John Birrell <jb@cimlogic.com.au> wrote:
> > PS: Yet another reason to run a NetBSD server or NetBSD API compliant
> > server on a Mach mk and built Pthreads on top of Mach C-Threads. 8-]
>
> Why run NetBSD at all then?

I don't want to start this thread off again, but here's my rationale for  
proposing and doing what I am already doing:

I have done Mach mk ports numerous times, and for my it is a fairly  
straightforward business, and I believe I have a thorough enough understanding  
of Mach internals to be successful at it and come up with something which  
will not only work, but perform well.

The Mach mk provides only the most basic functions.  Mach-UX relies on a OS  
server to provide an API.  Or, in case it is Mach-US we're dealing with,  
emulation libraries to possibly provide multiple APIs on a per process basis.

However, there are a bunch of goodies that come in the clue bag with this,  
and two of them I particularly like: 1.) kernel multithreading and 2.)  
multiprocessing.

It is a fully threaded kernel, and a rock-solid, fast kernel thread API is  
available to the user, which can be easily adapted to other threading API's if  
so desired, such as POSIX3.1c threads (Pthreads).

Further, I believe, that the fact that Mach mk's are by design meant to be  
multiprocessing kernels, makes it very easy to support multiprocessor  
environments.  To me, it makes more sense to take building blocks meant to  
support a particular function, than coax something that isn't meant to provide  
multiprocessing to provide multiprocessing.

And since Mach mk's 3.0 and up, even non-shared memory multiprocessor  
environments are possible and easily implemented.  The APIs themselves have no  
clue what it is below their ports to the mk (99.9% of the time).

The whole OS design is much more modular, which makes porting easier as well.  
 NetBSD has done a tremendous amount of porting work, which is easily  
absorbed.

IMHO, NetBSD is a very fine uniprocessor OS.  Efficiency for a different  
environment might need a different approach than driving a uniprocessor OS to  
be a multiprocessor OS.  Especially since there are no threads in the current  
kernel, IMHO, this job can never been of great efficiency.  It'll work, no  
doubt, but it won't be the best we can do.

Because the NetBSD server's API will be a superset of the current NetBSD API,  
 current apps will continue to run at the very least after recompilation.   
With a little extra effort, even binary compatibility can be provided.

The argument that Mach mk has more overhead than traditional architectures is  
not true per se.  Multithreading provides for significant advantages even on  
uniprocessor architectures when high I/O demands are to be serviced.  For  
efficient multiprocessing, threading is a requirement, not an option.  And  
predominantly userland threading implementations just don't cut it(TM).

That's my story.  Comments welcome, flames >/dev/null.

We'll see what happens.

--
Christian Kuhtz <ckuhtz@paranet.com>