From: Tom Tucker Subject: Re: [RFC,PATCH] svc: Modify svc_xprt_create to take a sockaddr Date: Mon, 21 Jan 2008 14:48:14 -0600 Message-ID: <1200948494.11003.71.camel@trinity.ogc.int> References: <20080121171105.29028.61809.stgit@dell3.ogc.int> <9ECEB764-A93C-4DF2-BB6E-273C33C02B6E@oracle.com> <1200938366.25562.14.camel@heimdal.trondhjem.org> <1200943495.25562.52.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain Cc: Chuck Lever , NFS list To: Trond Myklebust Return-path: Received: from 209-198-142-2-host.prismnet.net ([209.198.142.2]:50190 "EHLO smtp.opengridcomputing.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753448AbYAUUkt (ORCPT ); Mon, 21 Jan 2008 15:40:49 -0500 In-Reply-To: <1200943495.25562.52.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Mon, 2008-01-21 at 14:24 -0500, Trond Myklebust wrote: > On Mon, 2008-01-21 at 13:30 -0500, Chuck Lever wrote: > > > Not sure what you are getting at here. > > > > The goal of using string transport identifiers in the RPC client is > > that the value of "proto=" could be passed directly to the RPC > > client. The way it works today, we have to add support in the NFS > > mount option parser for any new RPC transport capability. > > > > One of the goals of the client-side transport switch has always been > > to allow new transport capabilities to be dynamically loaded without > > needing to make code changes to the NFS client to support them. > > > > For example, it would be nice to have an SCTP transport capability, > > or a single-socket-per-client UDP transport capability, in addition > > to the default socket-based transports we have now. With the current > > arrangement, we'll have to add code in the NFS mount option parser to > > allow users to select these. If the proto= value were simply passed > > through, it would be simple for the RPC client to match the value to > > an identifier string specified by the new transport. > > It is also important to be able to check arbitrary user data such as > that provided in the mount command for sanity. It should be a > requirement that we do that in one place only, else we'll be chasing > down security issues until the cows come home. I don't see this particular case as an issue. The transport class name is used to search a list of registered transport types. It seems to me that the point is _not_ having to encode semantic meaning in the option parsing so that you don't have to a) centralize all options parsing and anticipate every required syntax, or b) chase down everywhere these assumptions are independently coded. > > IOW: I don't care if you want to pass the 'proto' argument as a string, > but I'm not at all convinced that we need to be passing unparsed mount > data to the RPC layer. > Fair enough. I don't know if this is relevant to your point, but we're passing the option all the way down to the transport layer beneath RPC. The RPC layer doesn't look at the string either, it just passes it down to the transport provider layer to see if anyone is interested. If not, -ENOENT. modprobe my_favorite_transport mount .... -o proto="my_favorite_transport_id_string" and it works... Maybe I'm being naive, but that seems flexible and secure provided that the transport layer code is not broken. > Trond > > - > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html