From: Tom Tucker <tom@opengridcomputing.com>
To: Greg Banks <gnb@sgi.com>
Cc: neilb@suse.de, bfields@fieldses.org, nfs@lists.sourceforge.net
Subject: Re: [RFC,PATCH 0/7] svc: Incremental svc patchset cleanup
Date: Tue, 09 Oct 2007 22:32:05 -0500 [thread overview]
Message-ID: <1191987125.16714.49.camel@trinity.ogc.int> (raw)
In-Reply-To: <20071010022408.GA20690@sgi.com>
On Wed, 2007-10-10 at 12:24 +1000, Greg Banks wrote:
> G'day,
>
> Compendium reply.
>
> On Tue, Oct 09, 2007 at 10:35:39AM -0500, Tom Tucker wrote:
> So what are the intended semantics of svc_find_xprt(,,0,2049) ?
> When called like that, it will reach into xprt->xpt_local assuming
> it's a sockaddr_in and match the passed port number against whatever
> it finds at bytes 2-3.
Sorry, I missed this question. My intent was that the filters were
hierarchical: class, af, port.
AF_UNSPEC, notwithstanding, a class of <null> never matches anything.
>
> Perhaps this function could be pruned back to only do what it needs
> to do right now, which is match on transport name?
>
Yes, it could.
>
> > Subject: [RFC,PATCH 7/7] svc: Place type on same line for new API
>
> ok
>
> Greg.
-------------------------------------------------------------------------
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
next prev parent reply other threads:[~2007-10-10 3:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-09 15:35 [RFC,PATCH 0/7] svc: Incremental svc patchset cleanup Tom Tucker
2007-10-09 15:37 ` [RFC, PATCH 1/7] svc: Don't copy xprt_class data into svc_xprt instance Tom Tucker
2007-10-09 15:37 ` [RFC,PATCH 2/7] svc: Rename xpo_release to xpo_release_rqst Tom Tucker
2007-10-09 15:37 ` [RFC, PATCH 3/7] svc: Move setting of XPT_LISTENER bit to svc_tcp_init Tom Tucker
2007-10-09 15:37 ` [RFC, PATCH 4/7] svc: Add a sockaddr length argument to the xpo_create function Tom Tucker
2007-10-09 15:37 ` [RFC, PATCH 5/7] svc: Remove extraneous debug svc_send printk Tom Tucker
2007-10-09 15:37 ` [RFC, PATCH 6/7] svc: Add svc API that queries for a transport instance Tom Tucker
2007-10-09 15:37 ` [RFC,PATCH 7/7] svc: Place type on same line for new API Tom Tucker
2007-10-09 16:14 ` Aaron Wiebe
2007-10-09 16:13 ` [RFC,PATCH 0/7] svc: Incremental svc patchset cleanup Tom Tucker
2007-10-10 2:24 ` Greg Banks
2007-10-10 2:39 ` Tom Tucker
2007-10-10 4:25 ` Greg Banks
2007-10-10 3:32 ` Tom Tucker [this message]
2007-10-10 4:26 ` Greg Banks
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=1191987125.16714.49.camel@trinity.ogc.int \
--to=tom@opengridcomputing.com \
--cc=bfields@fieldses.org \
--cc=gnb@sgi.com \
--cc=neilb@suse.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox