From owner-freebsd-current Fri Sep 8 19:13:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA24303 for current-outgoing; Fri, 8 Sep 1995 19:13:48 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA24293 for ; Fri, 8 Sep 1995 19:13:45 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id TAA00286; Fri, 8 Sep 1995 19:12:37 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id TAA24824; Fri, 8 Sep 1995 19:14:45 -0700 Message-Id: <199509090214.TAA24824@corbin.Root.COM> To: Terry Lambert cc: current@freebsd.org, mckusick@mckusick.com Subject: Re: BROAD-BASED FS CHANGES In-reply-to: Your message of "Fri, 08 Sep 95 18:39:34 PDT." <199509090139.SAA10569@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 08 Sep 1995 19:14:44 -0700 Sender: current-owner@freebsd.org Precedence: bulk >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