On Sat, 2009-03-28 at 20:29 +0300, Benny Halevy wrote:
> On Mar. 28, 2009, 20:23 +0300, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote:
> > On Sat, 2009-03-28 at 11:20 +0300, Benny Halevy wrote:
> >> On Mar. 28, 2009, 3:39 +0300, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote:
> >>> On Mar 27, 2009, at 8:06 PM, "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
> >>> wrote:
> >>>
> >>>> On Fri, Mar 27, 2009 at 06:01:48AM +0300, Benny Halevy wrote:
> >>>>> From: Andy Adamson <andros@xxxxxxxxxx>
> >>>>>
> >>>>> Note: the NFSv4.1 client also uses (and declares) this pointer.
> >>>> OK. Ack from trond?
> >>>
> >>> First, someone would need to remind me why it is necessary, and add
> >>> that justification to the changelog.
> >> First time this is used in this patchset is here:
> >> [PATCH 35/47] nfsd: minorversion support for the back channel
> >>
> >> The client uses cl_private to determine the minorversion
> >> (via a struct nfs_client *) to be set in the compound header,
> >> and to know when to generate a SEQUENCE op.
> >> Similarly, the server puts a struct nfs4_callback * in
> >> there for callback compounds' CB_COMPOUND and CB_SEQUENCE.
> >
> > Why would the rpc_client need to know and track minor versions? That is
> > an NFS protocol specific thing.
>
> Agreed. the rpc_client doesn't know anything about the minor version.
> This is why we store it in a void *cl_private.
>
> >
> > Besides, the caller should always know what minor version it is using.
> > It shouldn't need a back-pointer in the rpc_client...
> >
>
> The back pointer is used in the xdr layer like this:
> struct xdr_stream xdr;
> + struct nfs_client *clp =
> + (struct nfs_client *)req->rq_task->tk_client->cl_private;
> struct compound_hdr hdr = {
> - .nops = 0,
> + .minorversion = clp->cl_minorversion,
> };
Just put that information in the RPC arguments where it _BELONGS_.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
