:>
:> 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.
Oops, sorry. I meant VFS. Same comments apply :-)
Despite all the arguing on the lists about VFS defaults and related
issues, nobody is doing or contemplating any actual work in this
area (i.e. VFS vs VOP) except for you, so you are not conflicting
with anyone.
:> 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.
Sounds like a good comment! You and I may understand the code just
fine, but the comments will help other developers.
: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.
Since you are the only one using it for the moment, do what you
feel is best. Once you've begun implementing code that uses the
new VFSops the appropriate place will become obvious and you can
make the change (if any) then.
:> 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> :)
For example, when I add certain functionality that was turned on
by a sysctl (which defaults to off), I feel that it is 'safe' to commit it
into the tree even though it may not have been tested comprehensively,
because nobody else is going to touch that code operationally.
I make the distinction between new code that isn't exercised by systems
built by other people and new code which is. The new code that isn't
exercised does not need the level of testing prior to commit that
code which is exercised by the masses needs. That's all. It's a
rule of thumb of mine.
:> 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
I don't know re: the BAFUG meeting. I might not be in town.
-Matt
Matthew Dillon
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
