Linux NFS development
 help / color / mirror / Atom feed
From: Tom Tucker <tom@opengridcomputing.com>
To: "J. Bruce Fields" <bfields@fieldses.org>, NeilBrown <neilb@suse.de>
Cc: nfs@lists.sourceforge.net, Greg Banks <gnb@sgi.com>
Subject: Re: [RFC, PATCH 3/3] knfsd: Modify write_ports to use svc_find_xprt service
Date: Thu, 11 Oct 2007 00:11:26 -0500	[thread overview]
Message-ID: <C3331AAE.3C378%tom@opengridcomputing.com> (raw)
In-Reply-To: <20071011034608.GC6684@fieldses.org>


Bruce:

What's the most efficient way for you to accept fixes/changes? I've been
going incremental because it's easy on me :-). Is this the best option for
you?

Regarding patch #6, I think the svc_find_xprt API _may_ be ok, but the
implementation was bogus (sorry). I _think_ the implementation is fixed in
the latest incremental. Greg can confirm.

WRT the suggestions below, I'll make those mods and test them tomorrow.

Thanks,
Tom

On 10/10/07 10:46 PM, "J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Thu, Oct 11, 2007 at 01:00:58PM +1000, Neil Brown wrote:
>> On Wednesday October 10, tom@opengridcomputing.com wrote:
>>> if (sscanf(buf, "%15s %4d", transport, &port) == 2) {
>> 
>> We should give a bit of thought to this parsing and future expansion.
>> Suppose we did want to pump more information into the kernel as has
>> been suggested (e.g. local IP address), we would want this code to
>> handle the new format correctly, probably by failing.
>> 
>> So maybe we really want
>> 
>>> if (sscanf(buf, "%15s %4d%c", transport, &port, &nl) == 2
>>            && nl == '\n') {
>> 
>> or something like that???
>> 
>> BTW, I'm fairly happy with the state of this patch set and suggest
>> that we aim for 2.6.24-rc1.  I still want to read through the final
>> code with all patches applied, but I should be able to find time for
>> that in the next month or so.  I don't expect any significant issues.
> 
> It seems OK to me, and it would be nice to get this batch in and have
> just the rdma stuff left to merge in 2.6.25.
> 
> But we're very short for time, and it appears that there's still some
> work to be done.  Certainly any user interfaces need to be sorted out,
> as we'll be stuck with them....
> 
> Other work to be done: these incremental fixes are helpful for reviewers
> like Greg who are keeping close watch on the process, but we need to
> submit a patch series that shows our changes with perfect hindsight, so
> we need to combine these with the previous patches.  I did this with the
> most recent two of Tom's 7-patch series; result here:
> 
> git://linux-nfs.org/~bfields/linux.git server-xprt-switch
> 
> I didn't apply patch #6 since Greg still had comments, and I haven't
> applied the most recent fixes.
> 
> If this isn't all ready by Friday (OK, maybe Monday) then I think we're
> out of time.
> 
> --b.



-------------------------------------------------------------------------
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

  parent reply	other threads:[~2007-10-11  5:02 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-11  2:23 [RFC, PATCH 0/3] svc: gnb review cleanup for transport switch Tom Tucker
2007-10-11  2:28 ` [RFC, PATCH 1/3] svc: Change sockaddr to sockaddr_storage in svc_create_xprt Tom Tucker
2007-10-11  2:28 ` [RFC,PATCH 2/3] svc: Fix bugs in svc_find_xprt Tom Tucker
2007-10-11  2:29 ` [RFC, PATCH 3/3] knfsd: Modify write_ports to use svc_find_xprt service Tom Tucker
2007-10-11  3:00   ` Neil Brown
2007-10-11  3:46     ` J. Bruce Fields
2007-10-11  5:09       ` Neil Brown
2007-10-11  5:26         ` Greg Banks
2007-10-11  5:37           ` Neil Brown
2007-10-11 14:56         ` J. Bruce Fields
2007-10-11  5:11       ` Tom Tucker [this message]
2007-10-11 15:25         ` J. Bruce Fields
2007-10-11 15:27           ` Tom Tucker
2007-10-11 17:04             ` J. Bruce Fields
2007-10-11  5:25 ` [RFC, PATCH 0/3] svc: gnb review cleanup for transport switch Greg Banks
2007-10-11 17:09   ` J. Bruce Fields
2007-10-11 20:30 ` J. Bruce Fields
2007-10-11 20:53   ` Tom Tucker
2007-10-11 21:14   ` Tom Tucker
2007-10-11 22:04   ` Tom Tucker
2007-10-11 22:08     ` J. Bruce Fields
2007-10-12 15:17       ` Tom Tucker
2007-10-12 15:41         ` J. Bruce Fields
2007-10-12 16:27           ` Tom Tucker
2007-10-12 21:40   ` Tom Tucker
2007-10-12 22:03     ` J. Bruce Fields
2007-10-12 22:30       ` J. Bruce Fields
2007-10-13  3:48         ` J. Bruce Fields
2007-10-13 12:35           ` Tom Tucker

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=C3331AAE.3C378%tom@opengridcomputing.com \
    --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