DragonFly BSD
DragonFly kernel List (threaded) for 2003-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Microkernel architecture?

From: Michael Neumann <mneumann@xxxxxxxx>
Date: Tue, 28 Oct 2003 11:14:35 +0100

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:

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

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



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]