[unios] m-kernel

[OJ Hickman]

Message-ID: <369C475D.7716@peak.org>
Date: Tue, 12 Jan 1999 23:12:30 -0800
From: OJ Hickman <hickman1@peak.org>
X-Mailer: Mozilla 3.04 (Win95; I)
MIME-Version: 1.0
To: David Jeske <jeske@home.chat.net>
Subject: Re: [unios] m-kernel
References: <199901111235.NAA04326@eduserv1.rug.ac.be> <369A6993.5CCD@peak.org> <19990111190114.G15764@home.chat.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David Jeske wrote:

> Microkernel which are pure IPC are not fast. Witness Mach pulling
> device drivers into the kernel, NT pulling device drivers into the
> kernel, QNX resorting to shared memory for low-latency communication.

I think that shared memory based systems show the most potential for
competitive performance. When ever posable services should be
implamented in shared class objects. These are both data and
code encapsulated in a shared object and so can serve as a form of IPC
or hardware driver. [Some process blocking may be needed]

> However, if you look carefully, it's less clear cut. The _idea_ of a
> microkernel is to 'isolate pieces', the idea of a macrokernel is to
> 'combine pieces'. Most good performance cases for micrkernels involve
> a subsystem designed in macrokernel fashion but exported in
> microkernel style. 

> If we want to be safe (which we do in a microkernel) we want to do
> something like:

> 1) have a disk driver export a raw disk device
> 2) have a partition server read this raw device and export partition devices
> 3) have an application access either a raw disk device or a partition in the
>    same manner

> However, microkernel's I've seen combine 1 and 2 into a single
> process. Essentially, they 'macro-ify' it, and export it through
> IPC. They do similar things for network stacks and display
> servers. When they don't, they witness a performance hit for having to
> 0cross 2 or more IPC boundaries.

Why not make 1 and 2 shared objects and have a storage server as 3?
I think a lot of IPC is avoidable without 'macro-ify' the over all
service.

> > It seems that all the work that can be done on kernels
> > themselves has been done.
> 
> I agree with this to a degree. Work on figuring out what is fast, what
> is slow, and where the performance bottlenecks are, has been done
> (witness countless kernels somewhere between microkernel/macrokernel).
> Work on architecting systems which provide safety has been done
> (Mach, QNX, KeyKOS, EROS).
> 
> Now all we need to do is listen, to both of them.

Yes.

_______________________________________________
"Imagination is more important than knowledge."
- Albert Einstein

Omer James Hickman - hickman1@peak.org - ojh@hotmail.com
http://members.tripod.com/~OJ_Hickman - updated 12/28/98