--GxcwvYAGnODwn7V8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 29, 2005 at 11:42:39PM +0100, Reinoud Zandijk wrote:
> Dear folks,
>=20
> running trough sys/kern/vnode_if.src to lookup the locking protocol for=
=20
> VOP_BMAP i stumbled on:
>=20
> #
> #% bmap               vp      =3D =3D =3D
> #% bmap               vpp     - U -
> #      =20
> vop_bmap {
>         IN LOCKED=3DYES struct vnode *vp;
>         IN daddr_t bn;
>         OUT struct vnode **vpp;
>         IN daddr_t *bnp;
>         OUT int *runp;
> };
>=20
> Wich is an inconsistency. The first part indicates the locking is not=20
> relevant but shouldn't change and the second part of the description tell=
s=20
> that struct vnode *vp should be locked on entry!

=46rom looking at the code, I think the "LOCKED=3DYES" is wishful thinking.=
=20
There are a lot of places that don't bother locking the vnode. Since the=20
node may already have been locked or we may not be able to lock it, I=20
think "=3D =3D =3D" is best.

> One of the others i've found is
>=20
> #
> #% strategy   vp      =3D =3D =3D
> #      =20
> vop_strategy {
>         IN struct vnode *vp;
>         IN struct buf *bp;
> };=20
>=20
> Shouldn't that be "L L L" for *vp ?

I don't think so. I wish it were, but it isn't. I think it's cleanest if=20
we move to the little-external-locking scheme used in SVR4 and which=20
Yamamoto-san wants to do.

Take care,

Bill

--GxcwvYAGnODwn7V8
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDtI0yWz+3JHUci9cRAv53AJ9VJyP6UPC/2F7UlglCy0ULnFhjrwCfXbE3
LPDDOZNOoTyIP6aOt4xlHX0=
=XuLT
-----END PGP SIGNATURE-----

--GxcwvYAGnODwn7V8--