On Thu, 26 Aug 1999, Matthew Dillon wrote: > :I've posted 2 times asking for someone to review these diffs: > : > :http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff > : > :Am I to take it that silence is accpetance? I'll be committing this > :to -current tonight or tomorrow unless I get feedback. > : > :See attached email for details. > : > :thank you, > :-Alfred Perlstein - [bri...@rush.net|alf...@freebsd.org] > :Wintelcom systems administrator and programmer > : - http://www.wintelcom.net/ [bri...@wintelcom.net] > : > :3) fh(open|stat|statfs) have been haphazardly implemented, meaning I > : won't be able to test them until tonight. > : > :Testers? Critics? Comments? please? > : > :If you're wondering why/what I'm doing, it's the kernel support > :for a lockd that I'm working on, as well as a cleanup I thought > :would make it easier to understand our filesystem code. > : > :I'm sure some people will be wondering: > :Why does VFS_CHECKEXP take a vnode and not a mount point? > :.. > :-Alfred Perlstein - [bri...@rush.net|alf...@freebsd.org] > > I've done a quick once-over of your patch. From the point of view of > the work I'm doing and the work Kirk will be doing later on, I do > not think the patch will cause any problems since you are adding new > VOPs for the most part rather then modifying (too many) existing VOPs.
VFS, not VOP. > Most of the work that Kirk and I will be doing will concentrate on > namei, locking, and I/O, which you mostly avoid in your patch. > > In general I like the idea of implementing reasonable defaults. > > I would ask two things though: > > * First, please add comprehensive /* */ comments in front of each > vfsnop_*() procedure explaining what it does, why it returns what > it returns, locking requirements (if any) on entry, and side effects > on return. This is just for readability. > > Do the same for all the procedures you are adding, in fact. The code isn't VOPs, it's VFS_ops, since they do nothing and don't block there really aren't any pre-requisites for calling them. VFS_CHECKEXP inherits the requirements of the old VFS_FHTOVP. However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only gripe is that exportability is determined by the filesystem, _then_ the vnode, making it more of a VFS op imo. > * I think you can safely commit any elements that are not used by > existing builds since they are not likely to impact existing > builds operationally. > > Then see what you have left over. If it is not significant, commit > that to. If it is significant, do more comprehensive testing on > what you have left over (i.e. that impacts existing builds) and > ask for another review after testing, before committing it. I'm totally lost here, can you re-phrase this? As far as the work done here, it's mostly a clean-up, no functional changes with the exception of the addition of the fh* syscalls. I guess you could call the VFS_CHECKEXP a functional change, but it's more of a re-org </pointy hair speak> :) > A working lock daemon would be totally awesome! The fh*() routines > you are adding are roughly what you (and we) need to make progress in > this area! Yes, i'd really like to get this off the ground. :) Btw, are you planning on attending any BAFUG coming up? I'd love to hear some of the preliminary stuff you are proposing for the filesystem. Thank you for your time, -Alfred To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message