hi,

> > 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.
> 
> Why?

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.

YAMAMOTO Takashi