> > > IMO, locking should be left to each filesystem implementations.
> > > it's a bad idea to force everybody to use the same one.
> > > (esp. when it's lockmgr. :-)
> > 
> > We used to do that. We then had each file system doing almost the exact 
> > same thing. We did not like that situation. So we made everything use 
> > lockmgr(), and life was better. The file system locking was much more 
> > maintainable, and we gained a fair bit of functionality.
> 
> almost the exact same != the exact same.
> > 
> > ... it as a requirement that file 
> > systems do real, hard-core locking. And given the state of things when I 
> > started, that was a very good thing.
> 
> why do you think that exposing a lock is a requirement?

I'd like to ask the same question differently.

Suppose a file system's VOP_LOCK() and VOP_UNLOCK()
are no-ops, and the file system can be trusted to
do the right thing (not really that hard) for the
primary VOPs (LOOKUP, READ, WRITE, etc). What
semantics would break?

From VOP_LOCK(9)
    VOP_LOCK() is used to serialise access to the
    file system such as to present two writes to
    the same file from happening at the same time.

Why? Is this a semantic of the file model? Or is
this a context to make things "easier" on the
underlying file system?



OBTW, VOP_RECLAIM(9) has a bug (I don't know the
real way to report it).
    The argument vp is the locked vnode to be reclaimed.
                           ^^^^^^
then later
    The vnode vp should not be locked on entry,
                        ^^^^^^^^^^^^^
    and will remain unlocked on return.

kern/vnode_if.src says U U U.

Regards,
	-gww