[pnfs] [Fwd: [PATCH] update exchange id reply to draft 9]

[Marc Eshel]

Let talk about it some more on the Wednesday call.

"J. Bruce Fields" <bfields at fieldses.org> wrote on 03/05/2007 11:18:51 AM:

> On Mon, Mar 05, 2007 at 11:13:33AM -0800, Marc Eshel wrote:
> > "J. Bruce Fields" <bfields at fieldses.org> wrote on 03/05/2007 11:02:56 
AM:
> > 
> > > On Sun, Mar 04, 2007 at 10:22:12PM -0800, Marc Eshel wrote:
> > > > static int nfs4_proc_exchange_id(struct nfs4_client *clp)
> > > > {
> > > >         nfs4_verifier verifier;
> > > >         struct nfs41_exchange_id_args args;
> > > >         struct nfs41_exchange_id_res res = {
> > > 
> > > If this is client-generated then we can allocate the minimum we know 
we
> > > need; looks like 40 bytes or so would do the job?  But just use some
> > > other constant--please don't change NFS4_OPAQUE_LIMIT.
> > 
> > Like the comment states this a temporary fix until we remove those 
struct 
> > from the stack.
> 
> Actually with the id down to a few tens of bytes it's probably OK on the
> stack.  So it's simple enough just to do something like:
> 
> +#define MAX_EXCHANGE_ID_SIZE 50
> +
>  struct nfs41_exchange_id_args {
>     nfs4_verifier *         verifier;
>     unsigned int          id_len;
> -   char             id[NFS4_OPAQUE_LIMIT];
> +   char             id[MAX_EXCHANGE_ID_SIZE];
>  };
> 
> > > > struct nfs41_exchange_id_args {
> > > >         nfs4_verifier *                 verifier;
> > > >         unsigned int                    id_len;
> > > >         char                            id[NFS4_OPAQUE_LIMIT];
> > > >         u32                             flags;
> > > >         struct nfs_impl_id4             impl_id;
> > > >         clientid4                       clientid;
> > > >         u32                             seqid;
> > > > };
> > > 
> > > I thought the implementation id was optional.  How about we just set 
it
> > > to zero?
> > 
> > But we still need to be ready to receive up to 1024 for each on of 
those 
> > fields from some server implementation.
> 
> Nah, we can just throw them away at xdr decode time.  We're not using
> them for anything, right?
> 
> --b.