[unios] m-kernel

[David Jeske]

On Mon, Jan 11, 1999 at 05:15:14PM -0500, Pat Wendorf wrote:
> Does anyone know if we can have the same level of performance (high
> performance I/O), out of a micro, that we would get out of a
> "no-kernel" or a monolithic kernel?

There are static-cases in which microkernel's have performed as well
as Macrokernels. Witness the QNX networking performance comparisons.

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
cross 2 or more IPC boundaries.

What we really should be striving for is performance _and_ safety. See
my other email on the subject.
 
> Does anyone know if a micro can be swapped out of memory and
> replaced with another?  This is just for the sake of flexibly, and
> can make the system reflective (as I understand it: adaptive to the
> way the user, uses the system).  If not, should we even be worrying
> about it?

You _can_ do anything you want. You can swap out Linux with another
kernel if you really want to. It's a question of which pieces of
functionality you are swapping out, how hard it is to code and
maintain, and what impact it has on the running system.

> I'd like to point to the QNX OS as a proof system.  They say it has
> infinite scalablity (something UniOS should strive for).  It is a
> m-kernel from the ground up. I had a demo for QNX, and it performed
> amazingly, however, the system is not cross platform compatible (in
> any way), expensive (for user and developer), and does not seem as
> flexible as we are hoping UniOS will be.

QNX is impressive. More than anything, it has impressive purity of
focus. However, they also have made tradeoffs. Their scheduler is
in-kernel, even though it's modular. Their serial drivers are accessed
with shared memory. They try to limit the number of levels of IPC a
given item has to go through. They don't support virtual memory, which
I believe is largly responsible for their extremely fast process to
process IPC copies. QNX is designed for embedded systems. We should
learn from it, but it, like everything in this world, has tradeoffs as
well.

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