Announcing DragonFly BSD!

[Matthew Dillon]

:I'm especially encouraged by the committment to fix the VFS subsystem
:so that stackable filesystems will really work,  by the caching/locking
:discussion,  and the acknowledgement that system configuration and packages
:need a publish-subscribe (not Matt's words) mechanism.
:
:Manuel Kasper's m0n0wall configuration system, XML-based, is
:really cool.  You could easily extend it to signed XML for
:trusted packages/components.
:
:Crypto and ACL filesystems could finally be done in a modular,
:stackable way.  Esp. if the messaging subsystem works as
:advertised.
:
:This announcement has made an otherwise dreary and mind-numbing day at
:work a little better, thanks.

    That is the intent.  Also the ability to develop and debug VFS layers
    as userland processes, or even run non-critical filesystems like msdosfs
    and cd9660 in userland outright.  

    Fixing VFS is probably the single most difficult problem that we will
    face.  Fixing DEV (which I am going to do as soon as I change the 
    I/O system over to using VM object ranges) is a lot easier because DEV
    entry points are already inherently asynch, or easily asynchronized.
    E.g. the IDE driver takes a request and 'queues' it for action.  The
    UFS filesystem, on the otherhand, executes the request synchronously
    in the context of the caller and may sleep/wakeup many times.  There is
    a big difference.

    Fixing VFS will require breaking it first... that is, it will require
    breaking its performance first by encapsulating the entire function set
    in a single thread which processes requests one at a time, whether they
    block or not.

    Once this is accomplished individual VFS devices, starting with the
    block conversion devices (VN, MD, etc) and ending with the filesystems
    (UFS, etc) can be 'asynchronized'.  The asynchronizing will require a
    huge amount of work.

    I'm probably not going to bother trying to remove the MP lock until 
    after DEV, VFS, VM, and KMEM have been fixed.  It's far more important
    to maintain a stable system for development while these crucial 
    subsystems are being worked on.  One reason why I decided to integrate
    MP lock manipulation in the LWKT scheduler (even though the LWKT subsystem
    does not itself need the MP lock to operate) is because I know I am going
    to be saddled with it for a long time and I might as well make it as
    painless as possible.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>