Re: Microkernel architecture?

[Jeremy Messenger <mezz7@xxxxxxx>]

On Thu, 02 Oct 2003 21:49:20 -0500, Pedro Giffuni wrote:

> This is off topic, (but just for reference and because there is not
> technical-chat list ...)
> 
> when you mentioned you wanted a userland VFS API, I recalled someone already did
> that: in fact, they turned everything into libraries and made the kernel very
> small... they called it an Exokernel:
> 
> http://www.pdos.lcs.mit.edu/exo.html

I have played with Exokernel long time ago. It was a very fast kernel, but
little unstable that time when I tried.

Cheers,
Mezz

> They invented softupdates, BTW :).
> 
> cheers,
> 
>     Pedro.
> 
> Matthew Dillon wrote:
> 
>> :Hi,
>> :
>> :I have a question: since so many of this new OS's features are commonly
>> :found in microkernel-based systems, why isn't DragonFly being planned as
>> :a microkernel design instead of a monolithic kernel with a few
>> :microkernel tricks? Or is DragonFly microkernel-based?
>>
>>     'microkernel' is a badly misused term.   While it is theoretically
>>     possible to build a microkernel, actually making it do useful things
>>     requires a level of integration that is fairly difficult to achieve
>>     in a microkernel design.
>>
>>     What we can do is move the bottomost layers, primarily device drivers,
>>     the networking layer, and filesystems, towards a microkernel-like
>>     message-passing design.  The KLD mechanism is capable of dynamic loading
>>     this layer.  Even so there are still a large number of heavily
>>     integrated structures which are simply passed by reference, such as
>>     'struct ucred'.  There are dozens such structures and it is the
>>     existance of these structures that makes it unlikely that the
>>     microkernel aspects of the system could be extended much beyond what
>>     we have already contemplated for DragonFly.
>>
>>     Nor would I particularly want to try.  I see no advantage at all in
>>     trying to convert the system wholely to a microkernel design, other then
>>     to slow it down and make the source code harder to understand :-)
>>
>>                                         -Matt
>>                                         Matthew Dillon
>>                                         <dillon@xxxxxxxxxxxxx>

-- 
bsdforums.org 's moderator, mezz.