Date: Tue, 9 Nov 1999 22:45:54 +0100 From: Eivind Eklund <eivind@FreeBSD.org> To: fs@FreeBSD.org Subject: Killing WILLRELE Message-ID: <19991109224553.G256@bitbox.follo.net>
next in thread | raw e-mail | index | archive | help
I'm looking at removing WILLRELE from the VFS specs, in order to get more sane semantics before introducing many more VFS consumers through stacking layers. I'm sending this as a 'HEADS UP!', a chance for people to object, and to give a chance at an advance view. Note that the present set of patches has not been tested beyond compilation; I'm reserving testing until after I've let people have the chance to scream at me (as I don't see a point in testing the changes unless people agree that they are a step in the right direction). There are presently three VOPs that use it: VOP_MKNOD Uses this for the 'vpp' parameter (should be the return vnode for the newly created node, I believe). The value is presently unusable; depending on which FS you call, it it is either set to NULL, set to point to a vnode (MSDOSFS), or just kept the way it was. (Note that MSDOSFS will leak vnodes as of today). I've been tempted to remove it, but am not entirely happy about that, as I think it might be useful for some stacked layers. Thanks to phk, I've been able to come up with patches to fix it - but these will increase the cost of VOP_MKNOD() (only slightly, I think, but I am not quite certain). The other alternatives are to remove the parameter, or to break the layering around ufs_mknod (basically, re-implement parts of VFS_VGET in it, and make it assume that it is only used with ffsspecops and ffsfifoops. This is presently correct, but introduces risk of breakage down the road.) Both of these alternatives are slightly more efficient than my preferred fix. Patches to make VOP_MKNOD use vpp normally are http://www.freebsd.org/~eivind/vop_mknod_fixed.patch It is possible that the NFS vp release would have been handled by common code if I hadn't added special code there, but I feel too uncomfortable around the NFS code/macros to try to find out. Patches to just remove the parameter are at http://www.freebsd.org/~eivind/vop_mknod_novpp.patch VOP_MKNOD has 5 callers. VOP_SYMLINK Same use of WILLRELE as VOP_MKNOD. Returns trash in some cases, OK values in others; relatively simple to fix, with Coda as the only complication. Patches to fix it are at http://www.freebsd.org/~eivind/vop_symlink_fixed.patch These will break Coda, which I'm planning to contact rvb about how to solve if people agree that WILLRELE should die. VOP_SYMLINK has 3 callers. VOP_RENAME WILLRELE on a bunch of parameters. Adrian Chadd is doing several things to VOP_RENAME which is relevant to this, so I'm keeping my hands off it for the moment. Hopefully, patches should be available later in the week. My next step along the sane semantics road will probably be to make freeing of cnp's reflexive - looking at the code that is there now, there looks like there are a number of bugs related to this at the moment, and it certainly makes the code much harder to follow. 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?19991109224553.G256>