On 19 Jul 2001, Assar Westerlund wrote:

> I did vop_mknod too, and I got another question for you.  Is
> layer_bypass going to be happy and should I apply this comment fix?

The important line of the comment is the one which got left out. :-) 

 * So all the calls which get us here have a locked vpp. :-)

As I believe you were changing the locking rules so that the *vpp comes
back locked, all will be well.

The one thing I'm unclear on (partly as I wasn't fully paying
attention :-) is that one of the other comments will hold true (just above
it):

         * (Assumes that the lower layer always returns
         * a VREF'ed vpp unless it gets an error.)

i.e. we always get passed a &vp - we never pass in NULL - and the lower fs
always fills one in if it doesn't return an error.

Take care,

Bill

> /assar
> 
> Index: layer_vnops.c
> ===================================================================
> RCS file: /cvsroot/syssrc/sys/miscfs/genfs/layer_vnops.c,v
> retrieving revision 1.6
> diff -u -w -u -w -r1.6 layer_vnops.c
> --- layer_vnops.c	2001/06/07 13:32:47	1.6
> +++ layer_vnops.c	2001/07/19 12:45:50
> @@ -393,8 +393,7 @@
>  				 descp->vdesc_vpp_offset,ap);
>  		/*
>  		 * Only vop_lookup, vop_create, vop_makedir, vop_bmap,
> -		 * vop_mknod, and vop_symlink return vpp's. The latter
> -		 * two are VPP_WILLRELE, so we won't get here, and vop_bmap
> +		 * vop_mknod, and vop_symlink return vpp's. vop_bmap
>  		 * doesn't call bypass as the lower vpp is fine (we're just
>  		 * going to do i/o on it). vop_loookup doesn't call bypass
>  		 * as a lookup on "." would generate a locking error.
>