On Jun 9, 2009, at 8:06 AM, Steve Dickson wrote:
Chuck Lever wrote:
I guess I just don't see why there has to be two switches for
this feature...
Because people seem to want to disable IPv6 support completely
on their
systems... Because there is a striking lack of infrastructure
for IPv6
support (including GUIs for configurating ip6tables, lack of IPv6
support in NetworkManager, no IPv6 support in tcp_wrappers,
inability to
disable IPv6 support in the kernel without hacking it out of
/etc/modprobe.conf, and so on)... Because TI-RPC is one level of
complexity, and IPv6 adds more complexity...
We can probably remove --enable-ipv6, and just stick with
--enable-tirpc, which implies IPv6 support, if you prefer that.
Actually I would like to do just the opposite... remove --enable-
tirpc
and stick with --enable-ipv6...
But it's a strange argument, when we have --enable-mount,
--enable-nfsv4,
and on and on.
Well, your examples are all defining functionality... not
libraries...
Right. I agree with Steve here. I think it makes sense to keep the
knobs we expect people to twiddle to be for features and not
necessarily for libs.
I really don't understand why having TI-RPC in a library is
important here.
--enable-tirpc is a feature knob. Forget that it happens to be in a
library. Either nfs-utils supports TI-RPC or it supports legacy RPC.
The external behavior of nfs-utils changes.
Legacy RPC is in a library too. It happens to be in a library that
is
included by default, so configure doesn't have to figure out where
RPC
support is and whether it is installed.
What's the difference?
Following this theory there should have been an --enable-glibc
which obviously misguided...
All configuration flags define functionality not supporting parts
of those functionalities....
That is exactly what --enable-tirpc does. The fact that it is in a
separate library is completely incidental. Either you get the new
code and new features (such as support for rpcbind v3/v4 and support
for IPv6) or you get the legacy behavior.
--enable-tirpc does more than look for a library. It switches in a
bunch of new code in nfs-utils itself, and enables new features and
new behavior.
I honestly don't see a distinction between --enable-gss, which adds
additional features in nfs-utils, but requires an additional library,
and --enable-tirpc, which adds additional features, but requires an
additional library.
Lets just have an --enable-ipv6/--disable-ipv6 flag and leave it to
the distros as to how they want to deal with it.
We already have a run-time switch for IPv6 support: It's /etc/
netconfig. Of course, that switch is entirely ignored if TI-RPC
support is not built in. The point is we don't need the configure
switch at all: if --disable-tirpc is specified, then no IPv6 support
is available. if --enable-tirpc is specified, then IPv6 support is
possible if there are visible inet6 transports in /etc/netconfig.
Now with that said, just because --enable-ipv6 is set, does not have
to mean *all* IPv6 support is there, especially if its not fully
baked.
More times that not, pieces of major new features are released in
multi updates... Maybe in this first IPv6 release only the supporting
components are enabled (ala libtirpc). In the next release client
side rpc.statd is enabled and so on...
Trickling things in a very slow and control pace makes it much easier
to manage new functionality... IMHO... and having the big hammer
(ala --disable-ipv6) is a comfortable thing when comes to maintaining
stability...
steved.
--
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
--
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
