Subject: Re: LK_SHARED for VFS_VGET/FHTOVP
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 05/27/2004 14:22:17
> > 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,
> specifically in the IO_SYNC case.
i were talking about in-core atime updating.
> > 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.
> > anyway it's better to (try to) keep VOP_LOCK and lockmgr different, IMO.
because VOP_LOCK is api and lockmgr is merely its current implementation.
> I mean if we ever go with a different lock system, we will need the same
> set of lock features, so changing lock systems will be simply changing the
> 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.