Re: Microkernel architecture?

[Bill Huey (hui) <billh@xxxxxxxxxxxxxxxxx>]

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 ?

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

Let me do some more reading. At least this might end up being interesting
conversation, don't know about the practicalities of getting something
like this up and going.

bill