From: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Subject: Re: [RFC,PATCH 00/20] svc: Server Side Transport Switch
Date: Wed, 29 Aug 2007 13:01:01 -0400
Message-ID: <EXNANE01EjQxzmWecm9000001e6@exnane01.hq.netapp.com>
References: <20070820162000.15224.65524.stgit@dell3.ogc.int>
	<46D5A3DE.8030208@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: nfs@lists.sourceforge.net
To: chuck.lever@oracle.com
In-Reply-To: <46D5A3DE.8030208@oracle.com>
References: <20070820162000.15224.65524.stgit@dell3.ogc.int>
	<46D5A3DE.8030208@oracle.com>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

At 12:50 PM 8/29/2007, Chuck Lever wrote:
>I think the client and server should use the *same* mechanism for 
>matching transports -- either a string *or* a protocol number (not 
>necessarily the IPPROTO number, but something mapped to it, so we can 
>add transport types like RDMA that don't have an IPPROTO number already).
>
>How do others feel about this?  String, or protocol number?

I think the string is the better approach, because it's self-describing
and maps nicely to the transport. Integers are more like the existing
code, however, and (very) easy to deal with.

At the moment, my code implements the integer method and it's
relatively clean, except for one thing. In nfs_show_mount_options()
(fs/nfs/super.c), the kernel attempts to print the mount options'
proto= setting based on the naked IPPROTO. This fails for rdma.
With a string, all it would have to do is copy the string.

Tom.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs