Microkernel architecture?

[Michael Neumann]

On Mon, 27 Oct 2003 16:24:41 -0800, Bill Huey <billh at xxxxxxxxxxxxxxxxx> 
wrote:

On Mon, Oct 27, 2003 at 07:54:12PM +0100, Michael Neumann wrote:
...
There's already a port of Linux 2.4 called L4Linux on top of the L4 
microkernel,
which has only a few percent less performance than running Linux 2.4 on 
bare
hardware and I've heard that 2.6 is nearly complete (of course L4Linux 
is still
monolithic, not client-server).
That's interesting, 2.6 eh ? link ?
Sorry, that should be 2.2 and 2.4 respectively.

I am dreaming of having the same for BSD, so that both could be run 
simultaneously
on top of L4 (or another fast 2nd generation microkernel). Currently, 
it's possible
to run as many L4Linux instances on top of L4 as you want, at least in 
theory. An
even improved jail if you want :-)
[new line rewrapped]

L4: l4ka.org
L4Linux: http://os.inf.tu-dresden.de/L4/LinuxOnL4/
Another interesting approach is SawMill:
http://www.research.ibm.com/sawmill/
L4 is interesting. The good thing about dfBSD, assuming I understand
this correctly, is that the token/LWKT threading stuff is can probably
be run as an L4 process or thread. Their respective preemption models
won't conflict unlike with FreeBSD-current, which probably would allow
for dfBSD to coexist cleanly with L4 as some kind of runtime image,
program or thread, and that would be bad ass. It would effectively be
a kind of dual kernel system just like RTLinux. Stuff like TimeSys
Linux have modified the kernel to be fully preemptive, a single kernel
system, which is a different RTOS model. Both systems  are legitimate,
but have different programming models and practices.
Since dfBSD's interrupt threading model is conceptually identical to
how typical RTOS kernels work, preemptable/reschedulable interrupt 
threads,
then something like L4 would be able to supply all the interrupt handling
logic using its stock RTOS facilities. It would almost be a 1:1 code
drop-in.

That has some REALLY interesting possiblities and would even be more
attractive if, say, dfBSD's interrupt handling code wasn't fully in
place and could serve as the main interrupt handling code for the
project. That would be a good time window to do a proof of concept and
sneek something in, a very worthy project. The only thing I can think
that would get in the way of a project like this is how complete or
compatible the interrupt chip handling stuff would be relative to what's
in dfBSD or Linux.
I'll forward this post to the L4 mailing list, as I am not enough 
competent yet
in answering these questions (only two weeks since I first heard about L4).

Regards,

  Michael