DragonFly kernel List (threaded) for 2006-02
Re: User-Space Device Drivers
:> 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. :)
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
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.