Date: Thu, 26 Aug 1999 10:27:47 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: hackers@FreeBSD.ORG, fs@FreeBSD.ORG, Michael Hancock <michaelh@cet.co.jp>, David Greenman <dg@root.com> Subject: Re: HEADS UP Reviewers. VFS changes to be committed. Message-ID: <199908261727.KAA23308@apollo.backplane.com> References: <Pine.BSF.4.05.9908260220590.6392-100000@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
: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 - [bright@rush.net|alfred@freebsd.org] :Wintelcom systems administrator and programmer : - http://www.wintelcom.net/ [bright@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 - [bright@rush.net|alfred@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. 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. * 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. 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! -Matt Matthew Dillon <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908261727.KAA23308>