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

Jeff Layton
2009-06-08T11:10:30Z

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.

--
Jeff Layton <jlayton@redhat.com>