On Jun 9, 2009, at 10:48 AM, Steve Dickson wrote:
Chuck Lever wrote:
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 think this is splitting hairs... my friend... the only reason
libtirpc is even in the picture is because we need RPC library
code that had IPv6 support. Remember we (i.e the NFS community) were
told by the glibc people that under no circumstances would we
be able add IPv6 support to the glibc code. So Bull came up with
the answer of using libtirpc and rpcbind. So libtirpc is a means
to an end... and that end is IPv6 support...
I think you are making my argument for me. The fact that TI-RPC
support could go into glibc (but hasn't because of politics) suggests
that --enable-tirpc has nothing to do with a particular library. It
is solely a feature knob, just like all the other --enable switches
in ./configure.
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.
-enable-gss cause two daemon to be build and get installed which
adds the Secure NFS functionality. --enable-tirpc only causes code
paths to change, it add no functionality unless Ipv6 is enabled.
TI-RPC is not just an IPv6 enabler. It also has interoperability
implications. Support for rpcbind v3/v4 has no dependence on IPv6.
You can use rpcbind v3 or v4 requests over IPv4, for example, which
provides a significantly richer set of functionality. One area of non-
IPv6 interest would be support for registering local services via
AF_UNIX -- this type of registering is actually authenticated, so it
is a good security feature.
So that's way I think all that is needed is an --enable-ipv6 flag.
Actually, the new statd is built only if --enable-tirpc is set. So,
yes: new code _and_ new components are provided if --enable-tirpc is
set. TI-RPC is very similar to Secure NFS functionality. Secure NFS
provides support for new RPC features known as RPCSEC GSS, and --
enable-tirpc provides support for new RPC features known as TI-RPC.
So again, I don't see any philosophical difference between --enable-
gss and --enable-tirpc.
However, --enable-ipv6 is unnecessary because we want, and have, run-
time switches for that support. We are forced to, because nfs-utils
has to run on kernels which may or may not support IPv6.
I am continuing to argue this point because getting rid of --enable-
tirpc will make our jobs a lot harder. The reason this knob is there
is to firewall the new code and keep upstream nfs-utils stable as we
integrate more and more support for TI-RPC.
If we call it --enable-ipv6, many distributions will say "so what, i
don't need that" and leave it turned off. We won't get the kind of
soak time we really need.
--
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
