Jeff Layton wrote: > On Mon, 08 Jun 2009 05:09:36 -0400 > Steve Dickson <SteveD@xxxxxxxxxx> wrote: > >> >> Jeff Layton wrote: >>> On Sat, 6 Jun 2009 11:00:41 -0700 >>> "Muntz, Daniel" <Dan.Muntz@xxxxxxxxxx> wrote: >>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Jeff Layton [mailto:jlayton@xxxxxxxxxx] >>>>> Sent: Saturday, June 06, 2009 4:12 AM >>>>> To: Mike Frysinger >>>>> Cc: linux-nfs@xxxxxxxxxxxxxxx >>>>> 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@xxxxxxxxxx> 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... I guess I just don't see why there has to be two switches for this feature... 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
