On Thu, Jul 10, 2008 at 01:27:47PM -0400, Chuck Lever wrote: > > On Jul 7, 2008, at 4:51 PM, Trond Myklebust wrote: > >> On Mon, 2008-07-07 at 15:44 -0400, Chuck Lever wrote: >> >>> If you would like connected UDP, I won't object to you implementing >>> it. However, I never tested whether a connected UDP socket will give >>> the desired semantics without extra code in the UDP transport (for >>> example, an ->sk_error callback). I don't think it's worth the >>> hassle >>> if we have to add code to UDP that only this tiny use case would >>> need. >>> >> >> OK. I'll set these patches aside until I have time to look into adding >> connected UDP support. > > That's not completely necessary... the one-shot + TCP changes just make > it nicer when the local rpcbind is not listening. Without these, the > cases where the rpcbind daemon isn't running, or doesn't support rpcbind > v3/v4 and the kernel was built with CONFIG_SUNRPC_REGISTER_V4, will cause > some delays before failing, but otherwise shouldn't be a problem. > > I think you can drop the patch to change rpcb registration to go over > TCP for now unless you already have a CUDP implementation you are happy > with. So actually in your original series of 7 I think that'd mean dropping numbers 5 and 6 and keeping the rest? I've lost track of the status of the 3 series you submitted on the 30th: "Remaining rpcbind patches for 2.6.27" - this one, probably ready after dropping 2 patches "rpcbind v4 support in net/sunrpc/svc*" - Do you still want this considered for 2.6.27? "NLM clean-ups for IPv6 support" - I think you were saying there's still a bug being tracked down in this series? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
