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