From owner-freebsd-fs Fri Nov 26 3: 5:22 1999 Delivered-To: freebsd-fs@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4FD5714F7F for ; Fri, 26 Nov 1999 03:05:13 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA10001; Fri, 26 Nov 1999 12:05:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA43398; Fri, 26 Nov 1999 12:05:11 +0100 (MET) Date: Fri, 26 Nov 1999 12:05:11 +0100 From: Eivind Eklund To: Michael Hancock Cc: Terry Lambert , fs@FreeBSD.ORG Subject: Re: namei() and freeing componentnames Message-ID: <19991126120511.E602@bitbox.follo.net> References: <19991125182159.B602@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from michaelh@cet.co.jp on Fri, Nov 26, 1999 at 09:12:57AM +0900 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Nov 26, 1999 at 09:12:57AM +0900, Michael Hancock wrote: > > Right now, after seeing how much chaos the VOP_RELEASEND stuff turned > > into and how many places other code is repeated, I'm tempted to go for > > a NDFREE() which can free struct nameidata, *including vrele/vput'ing > > aquired vp*, and which takes flags to indicate if it is to leave some > > resources behind. > > NDFREE() makes sense, though I'd do the vrele/vput part later as a > separate step. In normal circumstances, I might agree. However, we have a 4.0 architectural changes freeze coming up, and if we are to handle this right, we should have free inhibition flags rather than flags saying what to free (in order to be able to change the definition without changing all callers, and in order to make the code obvious at the point of call). This means that if we do not do it now, we really should wait to get close to 5.0-RELEASE to do this, or we need to sync the change into the 4.0 API after release, in violation of our releases-have-stable-APIs policy. I would like to avoid both of these options. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message