From: "Talpey, Thomas" Subject: Re: [PATCH 12/19] NFS/SUNRPC: support transport protocol naming Date: Tue, 11 Sep 2007 08:16:45 -0400 Message-ID: References: <46E5E07C.5070202@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: nfs@lists.sourceforge.net To: chuck.lever@oracle.com Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1IV4g3-00014z-E9 for nfs@lists.sourceforge.net; Tue, 11 Sep 2007 05:17:11 -0700 Received: from mx2.netapp.com ([216.240.18.37]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1IV4g6-0001ae-1j for nfs@lists.sourceforge.net; Tue, 11 Sep 2007 05:17:16 -0700 In-Reply-To: <46E5E07C.5070202@oracle.com> References: <46E5E07C.5070202@oracle.com> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net At 08:25 PM 9/10/2007, Chuck Lever wrote: >Just a general comment. > >I don't see how this will make it easier to add NFS client support for >new RPC transports. I thought we recently decided to pass down a >string, and let the transports themselves register a netid that matches it? > >For example, these changes are required to support RDMA -- you can't >just ship a new RDMA SUNRPC transport module and expect it to work >without this ULP change. Likewise, if we add SCTP sometime in the >future, will we want to make this same kind of modification to the NFS >client before the SCTP SUNRCP transport module works correctly? Well, the "string" discussion was in the context of the server-side switch, but you call out a good goal to add transports without touching the upper layers. I think the choice of integer or string is basically arbitrary. One way or the other, some mapping from identifier to the actual transport is defined. Strings are a little more self-describing, but in the end harder to maintain for that very reason. That's the way my thinking came down, anyway. One way to allow extension would be to add a proto=%d syntax, this would obviate having to change the many uses of xprt->prot and rpc_create() in the in-kernel clients (another reason I chose to stick with int's). Happy to code that... Tom. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs