Date: Fri, 08 Sep 1995 19:14:44 -0700 From: David Greenman <davidg@Root.COM> To: Terry Lambert <terry@lambert.org> Cc: current@freebsd.org, mckusick@mckusick.com Subject: Re: BROAD-BASED FS CHANGES Message-ID: <199509090214.TAA24824@corbin.Root.COM> In-Reply-To: Your message of "Fri, 08 Sep 95 18:39:34 PDT." <199509090139.SAA10569@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>It seems to me as if the freeing of the buffer on an error (or on >success, in some cases) is *too* well hidden and is a violation of >interface layering semantics. I think I agree (after a two minute review of the code :-)). >The SAVENAME flag would still be there, but callers setting the >SAVENAME flag would be made responsible for discaring the buffer >after making the VOP call with the resulting lookup data instead >of expecting the VOP call to free it for them. This seems reasonable. >There are very few locations where this will result in an >additional call to free the allocated nami pathname buffer (the >call is tenatively defined to be nameifree() in vfs_lookup.c). >./kern/kern_exec.c Hmm, I don't see why you would need an extra free in kern_exec.c, but perhaps I'm missing something. >Let me know if this is a problem; if it isn't, I'll go ahead with >it some time this weekend. As long as it doesn't (further) break the filesystem stackability, I don't have a problem with it. -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509090214.TAA24824>