Subject: Re: LK_SHARED for VFS_VGET/FHTOVP
To: YAMAMOTO Takashi <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 05/26/2004 22:55:49
Content-Type: text/plain; charset=us-ascii
On Thu, May 27, 2004 at 02:22:17PM +0900, YAMAMOTO Takashi wrote:
> > > i thought that we're talking about ITIMES.
> > > (you mentioned about biglock and i said "atime-update".)
> > We are. VOP_UPDATE() is how ffs_read() pushes the atime-update,=20
> > specifically in the IO_SYNC case.
> i were talking about in-core atime updating.
And that's how atimes actually get pushed to be a specific time even=20
> > > i don't see why VOP_UPDATE is related to biglock.
> > > can you be more descriptive?
> > VOP_UPDATE is related to all of this in that it is modifying data. It is
> > doing things it needs a writer lock for. Is that clearer?
> no. what i asked was, why biglock is related to VOP_UPDATE while
> it doesn't affect VOP_GETATTR.
Ahhh... Now I understand. Because VOP_GETATTR cheats. I'd rather we not=20
have other code paths start cheating just because it does.
> > > anyway it's better to (try to) keep VOP_LOCK and lockmgr different, I=
> > Why?
> because VOP_LOCK is api and lockmgr is merely its current implementation.
And how have we defined the api's interface to be something different from=
the lockmgrs? I admit everyone's been flexible on this point...
> > I mean if we ever go with a different lock system, we will need the sam=
> > set of lock features, so changing lock systems will be simply changing =
> > flags we pass in and changing the few actual lockmgr calls.
> i don't think that "the same set" here is an appropriate claim
> because you're suggesting to introduce a somewhat new lock feature,
> LK_DOWNGRADE, to VOP_LOCK.
Well, right now we have LK_EXCLUSIVE, LK_SHARED, LK_INTERLOCK, LK_RETRY,
LK_CANRECURSE, LK_SETRECURSE, and LK_NOWAIT as exposed (and used) flags.
So it sure looks like we're using a lot of the lockmgr interface for=20
I'm not going to say you HAVE to use LK_DOWNGRADE (that would be silly). I=
just think we're at a point where we're really intertwined with lockmgr,=20
and that LK_DOWNGRADE would be easier as it does exactly what you want to=
do. But perhaps we should add a VOP_LOCKADJ() (for lock adjust) for it, as=
it has the different semantic that the lock has to be locked on entry.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----