Re: Microkernel architecture?

[Michael Neumann <mneumann@xxxxxxxx>]

On Mon, 27 Oct 2003 16:24:41 -0800, Bill Huey <billh@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