On Fri, 5 Feb 2010 13:17:57 -0500 Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > I can sort of buy the argument for leaving out the earlier #ifdef > > > around the default_value() function. > > > > > > If you change this one though, then lookups will still return IPv6 > > > addresses by default even when IPV6_SUPPORTED isn't set. IOW, in the > > > absence of a proto= option, you'll pass AF_UNSPEC to getaddrinfo and > > > get IPv6 addresses. I don't think that's what we want here for a > > > non-ipv6 enabled nfs-utils. > > > > OK, agreed. This setting is actually not determining the meaning of any > > of the netids, but rather it is determining the default address family > > if _no_ netid is specified. > > > > Correct. Ok, I'll respin and repost with the ifdef's in default_value() > removed. New patch sent. Just for giggles, I tested this by building a tirpc-enabled/ipv6-disabled nfs-utils and setting Defaultproto=tcp6. It does indeed set the address family to IPv6: # mount -v opensolaris:/export/public /mnt/test mount: no type was given - I'll assume nfs because of the colon mount.nfs: timeout set for Fri Feb 5 14:51:01 2010 mount.nfs: trying text-based options 'vers=4,addr=feed::23,clientaddr=feed::22' ...and the mount succeeds. So in that situation and also when proto=tcp6 is specified, someone can mount an IPv6-capable server even with a nfs-utils that isn't built for IPv6 as long as it has tirpc support. Is that a good thing? I'm not sure -- statd won't work over IPv6 in that case, for instance. Would it be better to have mount.nfs fail to use IPv6 addrs at all when not built with IPv6 support? -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
