From owner-freebsd-current Mon Mar 9 03:18:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA22569 for freebsd-current-outgoing; Mon, 9 Mar 1998 03:18:17 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA22564 for ; Mon, 9 Mar 1998 03:18:15 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id JAA22565 for ; Mon, 9 Mar 1998 09:59:17 GMT Date: Mon, 9 Mar 1998 18:59:17 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system In-Reply-To: <19980309082056.A13758@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 9 Mar 1998, Ollivier Robert wrote: > > What effort? Yours? I dont see anyone working on the FS stacking > > effort. I started recently. Mike Smith committed some glue recently. The next round of patches will give some immediate gratification. People have been working on stacking in our tree since April 97 as far as I can tell and have made some progress. I think BSDI has spent quite a bit of time with FS stacking too. What I found surprising is that no one put a higher priority on some fundamental stuff like releasing memory and lock state at the same layer as they were acquired. Imagine trying to map a returning vpp that was vrele'd, or worse vgone'd, before it reached your layer. Kirk says that this is one of the first things that should be done. Regularizing wasn't done when the VFS layer was inserted in the middle because the pre-VFS code was written that way and I guess the various people working on it found it expedient to just leave it the way it was. It wasn't as much of an issue in pre-VFS days. I'm working on this now for the most visible offenders. My next round of patches will fix the dvp argument rele behavior of VOP_CREATE, VOP_MKNOD, VOP_MKDIR, and VOP_SYMLINK. My initial target was just VOP_CREATE, but my list has grown as I discovered dependencies. So far lock state doesn't look like a problem to fix either, but I'll tackle it later after all the rele behavior has been fixed for all offending VOPs. I'm looking for special cases while working on this sweep. This divide and conquer grunt work has paid off in other ways, I've found a missing vput in DEVFS's symlink implementation and let Julian know. Terry's argument for making nameidata "reflexive" is the same issue. Regards, Mike Hancock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message