Date: Fri, 26 Nov 1999 12:05:11 +0100 From: Eivind Eklund <eivind@FreeBSD.ORG> To: Michael Hancock <michaelh@cet.co.jp> Cc: Terry Lambert <tlambert@primenet.com>, fs@FreeBSD.ORG Subject: Re: namei() and freeing componentnames Message-ID: <19991126120511.E602@bitbox.follo.net> In-Reply-To: <Pine.BSF.3.95LJ1.1b3.991126091024.3272A-100000@sv01.cet.co.jp>; from michaelh@cet.co.jp on Fri, Nov 26, 1999 at 09:12:57AM %2B0900 References: <19991125182159.B602@bitbox.follo.net> <Pine.BSF.3.95LJ1.1b3.991126091024.3272A-100000@sv01.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991126120511.E602>