From owner-freebsd-stable@FreeBSD.ORG Wed Jul 16 13:28:40 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5662437B401 for ; Wed, 16 Jul 2003 13:28:40 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97D5343FA3 for ; Wed, 16 Jul 2003 13:28:39 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9/8.12.6) with ESMTP id h6GKSdVI094298; Wed, 16 Jul 2003 13:28:39 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9/8.12.6/Submit) id h6GKScah094297; Wed, 16 Jul 2003 13:28:38 -0700 (PDT) Date: Wed, 16 Jul 2003 13:28:38 -0700 (PDT) From: Matthew Dillon Message-Id: <200307162028.h6GKScah094297@apollo.backplane.com> To: Michael Sierchio References: <200307161941.h6GJfoI4093997@apollo.backplane.com> <3F15B186.9000108@tenebras.com> cc: stable@freebsd.org cc: kernel@crater.dragonflybsd.org Subject: Re: Announcing DragonFly BSD! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2003 20:28:40 -0000 :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