From owner-freebsd-hackers Sat Aug 28 20: 9:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 55C4914F7A; Sat, 28 Aug 1999 20:09:21 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.8.8/8.8.8) with ESMTP id NAA17700; Sat, 28 Aug 1999 13:25:34 -0700 (PDT) (envelope-from bright@wintelcom.net) Date: Sat, 28 Aug 1999 20:25:34 +0000 (GMT) From: Alfred Perlstein To: Poul-Henning Kamp Cc: Erez Zadok , Matthew Dillon , hackers@FreeBSD.ORG, fs@FreeBSD.ORG, Michael Hancock , David Greenman Subject: Re: HEADS UP Reviewers. VFS changes to be committed. In-Reply-To: <6793.935785947@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Aug 1999, Poul-Henning Kamp wrote: > > Uhm, have any of you actually ever looked at src/sys/kern/vnode_if.src ? I can't really tell if you are commenting on the diffs I provided or if you are commmenting on the comments I have recieved, or both. Either way, could you elaborate a bit? I was hoping for your input on this issue. thank you, -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] > > Poul-Henning > > In message <199908272018.QAA22373@shekel.mcl.cs.columbia.edu>, Erez Zadok write > s: > >In message <199908261727.KAA23308@apollo.backplane.com>, Matthew Dillon writes: > >[...] > >> 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. > > > >Moreover, I would strongly recommend xplicitly documenting the following: > > > >- which function args are in-args and which are out-args? > > > >- does the function takes any allocated memory that it is expected to free? > > > >- is the function expected to allocate any memory objects that have to be > > freed elsewhere? > > > >- does the function increase or decrease any reference counts of any objects? > > Is it expected to? > > > >These and other requirements are essentially the "interface" between the VFS > >and lower-level file systems. Figuring out this stuff on every OS and OS > >revision (esp. when the VFS changes so often---linux) was the longest most > >frustrating task I faced when writing my Wrapfs stackable f/s module for > >solaris, freebsd, and linux. I wish documentation had been in place. > > > >> * 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. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message