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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Wintelcom systems administrator and programmer
- http://www.wintelcom.net/ [[EMAIL PROTECTED]]
>
> Poul-Henning
>
> In message <[EMAIL PROTECTED]>, Erez Zadok write
> s:
> >In message <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
