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

Chuck Lever
2009-06-08T14:16:31Z

On Jun 6, 2009, at 4:02 PM, 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.

The reason to build without it is that libtirpc is largely untested
code (on Linux), and the nfs-utils support to use TI-RPC is also
largely untested. I think the default config settings should
configure a safe, known-working configuration, not the most advanced
configuration.

As much as I like the idea of wider testing, the idea that we happen
to be testing with live users is not inviting. But I guess it's all
we've got at this point.

>> 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?"

Yes, there is, I would argue.

> 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?"

In many other cases (libevent, libnfsidmap, libgssglue, and so on),
configure currently bails if the library is not present. If we make --
enable-tirpc drop back automatically, why wouldn't we also do this for
the others?

Frankly, I think dropping back automatically is not a good idea. The
torrent of messages that configure normally spits out means that
messages about a missing libtirpc are going to be missed in most
cases, and folks will think that because they specified --enable-tirpc
on the configure command line, that's the build they got.

> So far, I'm leaning toward "No" on the first question and to
> "automatically fall back" on the second question.

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