Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Sep 1995 18:39:34 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        current@freebsd.org
Subject:   BROAD-BASED FS CHANGES
Message-ID:  <199509090139.SAA10569@phaeton.artisoft.com>

next in thread | raw e-mail | index | archive | help

I want to do some rather wholesale changes to the way nai return
values are treated; specifically, I'd like to remove the buffer
freeing for cn_pbuf in the componentname substructure of nameidata
in each of the following places:

./i386/ibcs2/imgact_coff.c
./isofs/cd9660/cd9660_vnops.c
./kern/kern_exec.c
./kern/vfs_syscalls.c
./miscfs/procfs/procfs_vnops.c
./miscfs/union/union_subr.c
./msdosfs/msdosfs_vnops.c
./nfs/nfs_node.c
./nfs/nfs_serv.c
./nfs/nfs_subs.c
./nfs/nfs_vnops.c
./ufs/ufs/ufs_vnops.c

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.

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.

Path name parsing is not at the same level, semantically, as
use of the parsed path for file system operations.

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).

./i386/ibcs2/imgact_coff.c
./kern/kern_exec.c
./miscfs/devfs/devfs_vnops.c
./miscfs/union/union_subr.c
./msdosfs/msdosfs_lookup.c
./msdosfs/msdosfs_vnops.c
./nfs/nfs_subs.c
./nfs/nfs_vnops.c
./ufs/ufs/ufs_lookup.c

Let me know if this is a problem; if it isn't, I'll go ahead with
it some time this weekend.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509090139.SAA10569>