Chuck Lever wrote: > 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@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... > > Yes, mount.nfs, showmount, and gssd are all working over IPv6. > rpc.statd and rpc.nfsd are coming soon. Good... Could we wait until rpc.statd and rpc.nfsd before we turn the switch? I thinking it would make testing a bit easier... > >> 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... 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
