Re: should we make --enable-tirpc the default in current nfs-utils?

Chuck Lever
2009-06-08T14:26:25Z

On Jun 8, 2009, at 9:36 AM, Steve Dickson wrote:
> Jeff Layton wrote:
>> On Mon, 08 Jun 2009 05:09:36 -0400
>> Steve Dickson <SteveD@redhat.com> wrote:
>>> Jeff Layton wrote:
>>>> On Sat, 6 Jun 2009 11:00:41 -0700
>>>> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jeff Layton [mailto:jlayton@redhat.com]
>>>>>> Sent: Saturday, June 06, 2009 4:12 AM
>>>>>> To: Mike Frysinger
>>>>>> Cc: linux-nfs@vger.kernel.org
>>>>>> Subject: Re: should we make --enable-tirpc the default in
>>>>>> current nfs-utils?
>>>>>>
>>>>>> On Fri, 5 Jun 2009 16:50:41 -0400
>>>>>> Mike Frysinger <vapier@gentoo.org> wrote:
>>>>>>
>>>>>>> On Friday 05 June 2009 13:36:34 Jeff Layton wrote:
>>>>>>>> On Fri, 5 Jun 2009 12:24:39 -0400 Mike Frysinger wrote:
>>>>>>>>> On Friday 05 June 2009 07:36:48 Jeff Layton wrote:
>>>>>>>>>> Doing this now would add wider testing exposure for these
>>>>>>>>>> codepaths and help flush out bugs in TIRPC+IPV4
>>>>>> codepaths. OTOH,
>>>>>>>>>> it means adding a new library dependency for packagers, or
>>>>>>>>>> they'll need to take the conscious step to
>>>>>> --disable-tirpc when they configure.
>>>>>>>>> or have the configure script dump a warning whenever
>>>>>> libtirpc is
>>>>>>>>> not used ...
>>>>>>>> The problem there is that these sorts of warnings tend to
>>>>>> get lost
>>>>>>>> in the noise. So then you have the situation where people
>>>>>>>> aren't
>>>>>>>> sure whether they built against libtirpc or not. Only running
>>>>>>>> ldd
>>>>>>>> against the binaries will tell you.
>>>>>>> the configure script knows whether it's going to be
>>>>>> building against libtirpc.
>>>>>>> it isnt going to happen randomly during `make`.
>>>>>>> AC_MSG_WARNING([
>>>>>>>
>>>>>>> You really should think about switching to libtirpc
>>>>>>>
>>>>>>> ])
>>>>>>>
>>>>>>> maybe it's different in Gentoo, but people report configure
>>>>>> warnings
>>>>>>> all the time ;)
>>>>>>>
>>>>>> Well, Gentoo probably has a larger percentage of people
>>>>>> compiling the sources. Other distros generally distribute the
>>>>>> binaries. But to be fair, it's not unreasonable to expect
>>>>>> people who are compiling from sources to know what they're doing.
>>>>>>
>>>>>>>>>> We could make it so that configure looks for libtirpc and if
>>>>>>>>>> it's not available, configures the build against legacy RPC
>>>>>>>>>> interfaces. I think this is a bad idea however. While
>>>>>> it should
>>>>>>>>>> "just work" either way, there are some small behavioral
>>>>>>>>>> differences when TIRPC support is built in. I think it's
>>>>>>>>>> probably better to make enabling and disabling TIRPC
>>>>>> a conscious step.
>>>>>>>>> i think this is the correct behavior for unspecified configure
>>>>>>>>> flags
>>>>>>>> In general, yes. In this case though I think it's reasonable to
>>>>>>>> force people compiling the package without tirpc
>>>>>> installed to take
>>>>>>>> the conscious step to either install the right libs and
>>>>>> headers, or
>>>>>>>> to add --disable-tirpc.
>>>>>>>>
>>>>>>>> I think doing so will lead to a more deterministic
>>>>>> outcome in this
>>>>>>>> situation. If that's a problem however, I'm willing to
>>>>>> listen to the
>>>>>>>> reasoning and reconsider...
>>>>>>> i just dont agree with having to re-run configure to "fix"
>>>>>> a condition
>>>>>>> that the configure script should already be able to handle.
>>>>>> but i'm
>>>>>>> speaking in general terms here, not specific to what you
>>>>>>> propose as
>>>>>>> that isnt exactly the same thing. i dont feel too strongly
>>>>>>> here,
>>>>>>> especially since it doesnt affect me in any realistic way.
>>>>>>> -mike
>>>>>> Ok, fair enough. I don't feel terribly strongly about this
>>>>>> either and that is the the conventional way that configure
>>>>>> options work (don't fail unless absolutely necessary). I'll
>>>>>> see about coding up a patch that makes --enable-tirpc the
>>>>>> default but falls back to legacy RPC code with a warning if
>>>>>> TIRPC libs/headers aren't present.
>>>>> Changing the default because the code isn't sufficiently tested
>>>>> strikes
>>>>> me as a particularly bad idea. If Red Hat wants more testing,
>>>>> distribute nfs-utils with TIRPC enabled in Fedora, and _then_
>>>>> change the
>>>>> default in nfs-utils after more testing has occurred. Delegating
>>>>> testing to unsuspecting end-users (especially people who need to
>>>>> rebuild
>>>>> in production environments) seems like an ideal way to cause real
>>>>> problems.
>>>>>
>>>> If users have TIRPC installed on their systems, why would we want
>>>> to
>>>> avoid using it? Pieces of this code (mount.nfs, for instance) are
>>>> pretty much complete and working. There's no real reason to build
>>>> these
>>>> apps against legacy RPC now if we can help it.
>>>>
>>>>> And ffs, don't change the existing configure behavior. When nfs-
>>>>> utils
>>>>> is supposed to build with TIRPC (e.g., when TIRPC is the
>>>>> default), the
>>>>> configure should fail if TIRPC isn't installed. Perhaps the error
>>>>> message on failure could suggest running configure with --
>>>>> disable-tirpc.
>>>>>
>>>> nfs-utils is already builds with TIRPC. It also builds with
>>>> legacy RPC.
>>>> So in this discussion the first question is, "Is there some
>>>> reason to
>>>> not build against TIRPC when it's available on the machine?"
>>>>
>>>> Second question: "Should make configure bail out when TIRPC isn't
>>>> available and force the user to specify --disable-tirpc on the
>>>> command
>>>> line, or should we make the build just fall back to legacy RPC
>>>> when the
>>>> right TIRPC libs/headers aren't present?"
>>>>
>>>> So far, I'm leaning toward "No" on the first question and to
>>>> "automatically fall back" on the second question.
>>> I concur on this approach... but would like to change the flavour
>>> a bit
>>> Meaning.. Lets take out any and all references to TIRPC and replace
>>> them with IPv6 support, since, ultimately, that's what were are
>>> talking
>>> about...
>>>
>>> So, if libtirpc exists, there will be IPv6 support. If not, there
>>> will
>>> not be IPv6 support...
>>
>> Yes, eventually we'll want to make IPv6 support default to "on" when
>> TIRPC is present. If you look at the code though, there are #ifdef's
>> for HAVE_LIBTIRPC and IPV6_SUPPORTED. These are currently
>> controlled by
>> separate configure options, but you cannot build in IPv6 support
>> without TIRPC.
>>
>> In the interest of phasing in this support slowly, Chuck and I are
>> proposing that we enable TIRPC by default now, and keep IPv6
>> support a
>> separate option for the time being. Eventually, we'll want to turn on
>> IPv6 support automatically when TIRPC is available. I think it makes
>> sense though to wait until we have some experience with TIRPC support
>> in nfs-utils before we go all the way with turning on IPv6 support by
>> default.
>>
> Is there *any* IPv6 code working at all? We can always call the
> support "experimental" until you guys are done...

Yes, mount.nfs, showmount, and gssd are all working over IPv6.
rpc.statd and rpc.nfsd are coming soon.

> 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. But it's a
strange argument, when we have --enable-mount, --enable-nfsv4, and on
and on.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com