--9JSHP372f+2dzJ8X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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".)
> >=20
> > We are. VOP_UPDATE() is how ffs_read() pushes the atime-update,=20
> > specifically in the IO_SYNC case.
>=20
> i were talking about in-core atime updating.

And that's how atimes actually get pushed to be a specific time even=20
in-core.

> > > i don't see why VOP_UPDATE is related to biglock.
> > > can you be more descriptive?
> >=20
> > 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?
>=20
> 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=
MO.
> >=20
> > Why?
>=20
> 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=
=20
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=
e=20
> > set of lock features, so changing lock systems will be simply changing =
the=20
> > flags we pass in and changing the few actual lockmgr calls.
>=20
> 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
VOP_LOCK().

I'm not going to say you HAVE to use LK_DOWNGRADE (that would be silly). I=
=20
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=
=20
do. But perhaps we should add a VOP_LOCKADJ() (for lock adjust) for it, as=
=20
it has the different semantic that the lock has to be locked on entry.

Take care,

Bill

--9JSHP372f+2dzJ8X
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAtYLlWz+3JHUci9cRAp2zAJ9faBoM8FqKybtDm1oVrz+LWKTgHwCeK+l+
gLmgfgcj4n8thNSGBTejh/E=
=gp9O
-----END PGP SIGNATURE-----

--9JSHP372f+2dzJ8X--