Subject: RE: CVS commit: src
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Gordon Waidhofer <email@example.com>
Date: 06/22/2004 01:26:54
> > > 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?
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.
The vnode vp should not be locked on entry,
and will remain unlocked on return.
kern/vnode_if.src says U U U.