[unios] m-kernel

[David Jeske]

On Mon, Jan 11, 1999 at 01:13:55PM -0800, OJ Hickman wrote:
> Pieter Dumon wrote:
> > From: Pieter Dumon <Pieter.Dumon@rug.ac.be>
> > 
> > Actually, what is not offered by a microkernel that is needed by
> > UniOS? Nothing. A _true_ microkernel offers everythign you want :
> > stability,flexibility,speed etc. 

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.

My common definition of microkernel is 'A small kernel which handles
machine specific tasks and which exports a simple interface to process
control and IPC . All functionality of the system, including drivers,
servers, etc, are then layered on top of these process and IPC
facilities.' A microkernel (by in large) asserts that macrokernel
orginizations are not 'safe' (i.e. they do not isolate bugs). A
microkernel chooses to use hardware protection mechanisms to achieve
safety. In most cases, this means a compromise between speed and
safety. 

Microkernel's exert an undue performance strain on 'layering' of
subsystems. If you do not build a mechanism in for optimizing out IPC
boundaries, and transparently merging levels of code, you, the
developer, will have to do it yourself over and over.


For example, the MIT Exokernel experimented with some ways to achieve
safety without compromising speed. I don't know if the Exokernel
people would agree, but in my mind, the logical extension of this idea
is 'let code live where it runs fast, and deal with the safety
problems in some other way'. This is what we should be shooting for
IMO. Take a look at some of the kernels which have done 'safe' code
migration.

> [Almost] **Every** OS project that I have researched uses some form of
> microkernel. They just very in the amount of control the kernel
> has of memory and task management and IPC/RPC implamention. [Even
> the Cashe Kernel is just a microkernel]

Depends what your definition of a microkernel is. What is yours?

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

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net