Re: User-Space Device Drivers

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:> Anyway, according to the main web site, it appears that DFly is
:> currently aiming to become a hybrid kernel and then later a true
:> microkernel.  I think these small steps are appropriate in order to gain
:> adoption and to do proper analysis along the way (while still getting
:> things done, unlike the Hurd teams).
:
:(Matt, correct and slap me silly if I'm wrong)
:
:As far as I can understand, DragonFly will never be completely monolithic. It 
:will have user-space device drivers (for filesystems and the like), but not 
:for actual hardware or things that are too important to live in userspace 
:(e.g. needed to boot and whatnot). The goal is to be more like the venerable 
:AmigaOS which used messages and ports in a very microkernel-like way without 
:actualy being a microkernel.
:
:Doesn't mean that a good userspace driver framework is useless. I think it 
:could be a boon for things like USB/Firewire/Bluetooth or anything else that 
:could be detached without warning.
:
:But don't let that discourage you. Welcome aboard anyway. :)
:
:Cheers,
:Emiel

    That's a good summary.  The intention is definintely to create a
    user-space framework that allows device and filesystem drivers to
    operate as user processes, but 'critical' devices such as the native
    TCP stack, native disk driver, and native filesystem support will 
    almost always stay inside the kernel simply from a performance
    perspective.

    There are several situations where user-space drivers are beneficial:

    * Developing or porting a new filesystem.

    * When crash protection is more important then performance.

    * For drivers which operate over LAN/WAN network protocols and whos
      complexity is too great (too likely to contain bugs) to operate
      within the kernel.

    * For drivers which do not require direct access to hardware.  E.G.
      filesystems, RAID layers, etc.

    We do not yet have a user-space device/VFS infrastructure, but
    the work I am doing in the buffer cache and VFS support is also
    designed to support that goal.  Specifically I have been transforming
    the buffer cache into an entity that can be directly accessed by high 
    level kernel mechanisms (where as right now it is accessed primarily by
    low level filesystem code), and then once I do that I will move all
    the filesystem data caches out of the filesystem(s) and into the high
    level file descriptor code.

    The result will be that cached read accesses to files will be satisfied
    directly from the buffer cache and not have to recurse down into the 
    filesystem, which further means that the filesystem can then operate
    via userland without completely destroying performance.

    Once I get that stuff done it will be possible to construct a userland
    VFS driver infrastructure.

    Having a userland VFS driver is going to be very important in our efforts
    to port other filesystems, particularly ZFS.  However, my expectation is
    that once such work becomes mainstream or becomes the system default,
    we will want to run it in the kernel rather then in userland or at least
    have the option of running it in the kernel.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>