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

Re: just curious


From: Ebo <dragonfly@xxxxxxxxxxxxxxxx>
Date: Thu, 17 Jul 2003 21:01:05 +0200
Cc: dillon@xxxxxxxxxxxxxxxxxxxx



Matthew Dillon wrote:
:Hi Matt,
:
:
:I Hope the project works out. It's ambitious but it
:sounds promising!
:
:Do you plan to work toward something like a
:microkernel-ish system? Some statements on the site
:seem to implicate this.
:
:E.

    Well, the traditional definition of a microkernel has a lot of negative
    connotations, which I blame on Mach.  DragonFly is definitely not going
    to be a traditional microkernel but it will retain many of the better
    qualities of a microkernel design.

For example, DragonFly will use messaging heavily but the messaging will
be a light-weight design that is, by itself, incapable of transiting a
protection boundary. The core messaging structures will not track pointers or message sizes, for example. Instead what we will do is
support the transiting of protection boundaries by creating port
abstractions which do the appropriate translation into and out of forms
that *can* cross a protection boundary.


In otherwords, we will be able to use messaging to be able to abstract
certain devices and VFS layers into userland, which is tradtionally considered to be 'microkernel design', but that abstraction is not going
to hogtie in-kernel implementations with overhead bloat nor are we going
to require protection separation for the majority of devices in what
would be considered a 'production' system.
-Matt
Matthew Dillon <dillon@xxxxxxxxxxxxx>

I think microkernels have moved on since mach, active projects like L4-descendents from Karlsruhe university (http://l4ka.org/) and fiasco from Dresden (http://os.inf.tu-dresden.de/L4/) appear to function quite well. I played around with those some weeks ago and was quite impressed (after being exposed to mach many years ago :-)

What lacks in most u-kernel implementations is some meaningful
userland "kernel." Moving stuff from the kernel to some kernel-ish
process (for lack of a better word) seems useful to me. If I
understand you correctly you're aiming at a best of both worlds
approach: 'simple' kernel and delegating complex issues to userland?
(millikernel? ;)

Another question, how far does the messaging go, i.e. would it
extend to something like network/grid computing?


E.





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