From: Chuck Lever <chuck.lever@oracle.com>
To: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: [PATCH 12/19] NFS/SUNRPC: support transport protocol naming
Date: Tue, 11 Sep 2007 12:03:12 -0400 [thread overview]
Message-ID: <46E6BC40.2090605@oracle.com> (raw)
In-Reply-To: <EXNANE01PMKSUW8VcOM000004ce@exnane01.hq.netapp.com>
[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]
Talpey, Thomas wrote:
> 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,
Oops. I thought it was about both sides.
> 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.
I guess I see it the other way. The user specifies a string.
Converting it to a number means something has to keep track of the mapping.
[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard
[-- Attachment #3: Type: text/plain, Size: 228 bytes --]
-------------------------------------------------------------------------
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/
[-- Attachment #4: Type: text/plain, Size: 140 bytes --]
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
prev parent reply other threads:[~2007-09-11 16:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-10 17:47 [PATCH 12/19] NFS/SUNRPC: support transport protocol naming Talpey, Thomas
2007-09-11 0:25 ` Chuck Lever
2007-09-11 12:16 ` Talpey, Thomas
2007-09-11 16:03 ` Chuck Lever [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46E6BC40.2090605@oracle.com \
--to=chuck.lever@oracle.com \
--cc=Thomas.Talpey@netapp.com \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.