On Sep 26, 2008, at Sep 26, 2008, 8:03 PM, J. Bruce Fields wrote:
On Thu, Sep 25, 2008 at 02:13:11PM -0400, Chuck Lever wrote:
On Sep 25, 2008, at 12:58 PM, J. Bruce Fields wrote:
But I'm willing to settle for it and let it be a lesson to us if it
turns out to cause more problems than expected.
I will be here to fix it if there is a problem. In this case, this
whole NFS/IPv6 thing is so complicated that I'm implementing just
what
is needed as we go along. We can fill in the niceties at a later
point.
/me is taking his cue from "lazy evaluation."
OK, fair enough, barring any other objections.
Today, if CONFIG_SUNRPC_REGISTER_V4 is enabled and svc_register()
can't
contact rpcbind's IPv6 listener and issue a v4 SET request, it
fails and
the RPC service is shut down.
The only area that might be trouble is when a sysadmin shuts off ALL
IPv6 in her network configuration, even if the kernel is build with
IPv6
support. The network layer should do the right thing and map the
IPv6
loopback address to the IPv4 loopback address automatically, but I
haven't tested this.
I'm also not convinced that people will try to install a 2.6 kernel
on a
distribution that was built for 2.4 or earlier kernels. There are
too
many missing pieces in the old distributions (like kernel module
utilities) to make it easy. So I'm not trying to make this
compatible
with every distribution since the beginning.
Is it 2.4-era distributions that's really the issue?
I'm merely trying to bound the amount of backwards-compatibility that
we realistically have to worry about. It could be more recent than
that, even.
I thought the userspace rpcbind stuff was still a bit experimental--so
that when the switchover is made to a kernel that supports rpcbind v4,
the userspace that's required will be more recent than that.
You can drop libtirpc, rpcbind, and the latest nfs-utils on older
distributions without much difficulty.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
