Date: Wed, 16 Jul 2003 13:28:38 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Michael Sierchio <kudzu@tenebras.com> Cc: kernel@crater.dragonflybsd.org Subject: Re: Announcing DragonFly BSD! Message-ID: <200307162028.h6GKScah094297@apollo.backplane.com> References: <200307161941.h6GJfoI4093997@apollo.backplane.com> <3F15B186.9000108@tenebras.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307162028.h6GKScah094297>