: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.
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
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
