On Mon, 08 Jun 2009 11:04:02 -0400 Steve Dickson <SteveD@xxxxxxxxxx> wrote: > 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... > Well, IPv6 support in statd would finish up the client side IPv6 support. IPv6 support in rpc.nfsd is really only going to be useful once we get mountd and exportfs finished. While IPv6 support is the driving reason for adding TIRPC support to nfs-utils, does it really make sense to turn on TIRPC and IPv6 support all at once? It seems like that'll mean twice the bug reports all at once. > > > >> 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... > Right. I agree with Steve here. I think it makes sense to keep the knobs we expect people to twiddle to be for features and not necessarily for libs. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
