> > > > ... 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?
> 
> Whatever access callers of the file system expected to be serialized that 
> now aren't. i.e. a case where a caller called VOP_LOCK() and expected an 
> exclusive lock is now in place. Especially if it expected that lock to be 
> held across a call to ltsleep().

yes, we have such callers, unfortunately.
they should be fixed eventually, IMO.

> Also, for things like delete and rename, would it be so easy? Or file 
> creation?

yes, it's easy.  see nfs client.

> > >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?
> 
> It is file system semantics. A call to write(2), barring errors, is 
> supposed to be atomic. Thus if you have two write calls that overlap, the 
> overlapping data are to have come from one call or the other, not some mix 
> of both.

because we use a single VOP_WRITE for write(2),
there's no need to expose vnode lock to upper layer for this reason.

YAMAMOTO Takashi