Re: Annoucning DragonFly BSD!

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    Hi Ken, excellent questions and I hope you don't mind me CCing to
    the kernel list for archival purposes.  I'll answer your other questions
    under separate cover.

:I was reading your description of "userapi" from your site, and I noticed
:that all syscalls go through a userland process, then are passed as
:messages to the kernel if need be. I'm curious about this, mainly because
:this sounds a heck of a lot like a microkernel. Which leads me to another
:question. Did you make sure that context switching is fast?

    The message passing into the kernel is not intended to be any more or
    less efficient then the current syscall mechanism.  The intention is
    to cleanup the USER<->KERNEL API, to create an encapsulation that can
    be asynchronized in the kernel (potentially run multiple syscalls in
    the kernel in parallel), and to support fully asynchronous system
    calls (support multi-threaded user programs without having to create extra
    contexts in the kernel).

    Context switching speed depends primarily on two things: (1) Base overhead
    for entering and leaving the kernel and (2) Additional overheads related
    to concurrency issues within the kernel (e.g. the MP lock, mutexes,
    whatever).  DragonFly takes a good whack at #2 and is only slightly slower
    then -stable (and far faster then -current), at least in regards to MP
    locked operations.  DragonFly depends on implied locks on curthread and
    curproc, certain features of the light weight kernel threading subsystem,
    and delayed priority adjustments for user->kernel and kernel->user
    transitions to reduce overhead.

						-Matt