From: Spencer Shepler (shepler@eng.sun.com)
Date: 10/04/01-06:46:56 PM Z
Date: Thu, 4 Oct 2001 18:46:56 -0500
From: Spencer Shepler <shepler@eng.sun.com>
Subject: Re: changes to nfs4_prot.x / protocol description
Message-ID: <20011004184656.O398@dhcp-aus08-227.sun.com>
On Thu, Sergey Klyushin wrote:
> > -----Original Message-----
> > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com]
> > Sent: Thursday, October 04, 2001 5:14 PM
> > To: 'shepler@eng.sun.com'; nfsv4-wg@sunroof.eng.sun.com
> > Subject: RE: changes to nfs4_prot.x / protocol description
> >
> >
> > Couple of things.
> >
> > It looks like the ordering of the change for issue 13 and that for
> > issue 126 has an unfortunate result. The addition of the lock type
> > was done after the rearrangement to put fixed-length stuff first,
> > so that the current LOCK4denied has a fixed-length field after the
> > lockowner, which the rearrangement for issue 126 was intended to
> > avoid.
> >
> The same for
My recent change to the stateid4, to fixed length, eliminates the need
to modify most of what you have pointed out.
> struct open_to_lock_owner4
This needs to be changed; how about
struct open_to_lock_owner4 {
stateid4 open_stateid;
seqid4 seqid;
lock_owner4 lock_owner;
};
> struct exist_lock_owner4
> struct LOCK_CONFIRM4args
> struct LOCKU4args ( if stateid4 won't be fixed length)
> struct OPEN_DOWNGRADE4args ( if stateid4 won't be fixed length)
> struct READ4args ( if stateid4 won't be fixed length)
> struct WRITE4args ( if stateid4 won't be fixed length)
These are all corrected with the change to stateid4
> struct CB_GETATTR4args
Both structure members are of variable size (nfs_fh4 and bitmap4) so
reordering will not help.
> struct CB_RECALL4args ( if stateid4 won't be fixed length)
stateid4 change corrects this as well.
I have updated the nfs4_prot.x (version 1.102) with the change listed
above. Located at:
http://www.nfsv4.org/rfc3010updates/nfs4_prot.x
Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:14 AM Z CST