--f+W+jCU1fRNres8c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 20, 2004 at 02:15:24PM +0900, YAMAMOTO Takashi wrote:
> > Well, what else should he have done? He has to move the sleepers from o=
ne
> > lock to another, given what he's doing (I looked hard at this at the ti=
me
> > it was added). At the time he decides to do the transfer, the sleepers =
are
> > ALREADY asleep on a lock. So there's no ffs-internal way to handle this=
;=20
> > the sleepers are already outside of the ffs code.
>=20
> i think that having some tricks in VOP_LOCK/UNLOCK/ISLOCKED is enough.
> (in addition to stopping exporting v_vnlock, of course.)

Please look at what he is doing. I do not see how tricks in VOP_LOCK &=20
friends will cover this. Or any tricks I can think of will add latency to=
=20
common code paths, and I'd rather have this lock merging going on than=20
that dealy. ;-)

Also, what is wrong with exporting v_vnlock? It simplifies and economizes=
=20
a lot of things.

Take care,

Bill

--f+W+jCU1fRNres8c
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFA1hJ4Wz+3JHUci9cRAr6yAJ9aA8EiGKJMsdZQnz9IHEWc8q32LgCeJBzl
RY/6pswbmSxA30ryuMFt0DI=
=5CT9
-----END PGP SIGNATURE-----

--f+W+jCU1fRNres8c--