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

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

[Jeff Layton]

Eventually, we most distros are going to want to build nfs-utils
against libtirpc in order to get IPv6 support. At some point, we'll
probably want to make building with IPv6 support the default. In the
meantime however, we need to get more testing exposure for the TI-RPC
codepaths. We'll probably start building Fedora's nfs-utils with TI-RPC
support in the near future.

The question that Steve D. has asked is whether we should also make
--enable-tirpc the default for the mainline nfs-utils tree?

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.

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.

Thoughts?

-- 
Jeff Layton <jlayton@redhat.com>

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

[J. Bruce Fields]

On Fri, Jun 05, 2009 at 07:36:48AM -0400, Jeff Layton wrote:
> Eventually, we most distros are going to want to build nfs-utils
> against libtirpc in order to get IPv6 support. At some point, we'll
> probably want to make building with IPv6 support the default. In the
> meantime however, we need to get more testing exposure for the TI-RPC
> codepaths. We'll probably start building Fedora's nfs-utils with TI-RPC
> support in the near future.
> 
> The question that Steve D. has asked is whether we should also make
> --enable-tirpc the default for the mainline nfs-utils tree?
> 
> 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.
> 
> 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.
> 
> Thoughts?

Makes sense to me to have upstream defaults set to what we expect
distributions to move to, assuming there aren't known regressions.

--b.

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

[Chuck Lever]

On Jun 5, 2009, at 12:10 PM, J. Bruce Fields wrote:

> On Fri, Jun 05, 2009 at 07:36:48AM -0400, Jeff Layton wrote:
>> Eventually, we most distros are going to want to build nfs-utils
>> against libtirpc in order to get IPv6 support. At some point, we'll
>> probably want to make building with IPv6 support the default. In the
>> meantime however, we need to get more testing exposure for the TI-RPC
>> codepaths. We'll probably start building Fedora's nfs-utils with TI- 
>> RPC
>> support in the near future.
>>
>> The question that Steve D. has asked is whether we should also make
>> --enable-tirpc the default for the mainline nfs-utils tree?
>>
>> 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.
>>
>> 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.
>>
>> Thoughts?
>
> Makes sense to me to have upstream defaults set to what we expect
> distributions to move to, assuming there aren't known regressions.

That's a big assumption, and it's exactly why we wanted to have some  
soak time in rawhide or Debian unstable before enabling it by default  
upstream.

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

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

[J. Bruce Fields]

On Fri, Jun 05, 2009 at 12:14:48PM -0400, Chuck Lever wrote:
>
> On Jun 5, 2009, at 12:10 PM, J. Bruce Fields wrote:
>
>> On Fri, Jun 05, 2009 at 07:36:48AM -0400, Jeff Layton wrote:
>>> Eventually, we most distros are going to want to build nfs-utils
>>> against libtirpc in order to get IPv6 support. At some point, we'll
>>> probably want to make building with IPv6 support the default. In the
>>> meantime however, we need to get more testing exposure for the TI-RPC
>>> codepaths. We'll probably start building Fedora's nfs-utils with TI- 
>>> RPC
>>> support in the near future.
>>>
>>> The question that Steve D. has asked is whether we should also make
>>> --enable-tirpc the default for the mainline nfs-utils tree?
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Thoughts?
>>
>> Makes sense to me to have upstream defaults set to what we expect
>> distributions to move to, assuming there aren't known regressions.
>
> That's a big assumption,

I'm confused--there are known regressions or there aren't.  (I'm not
talking about unknown regressions....)

> and it's exactly why we wanted to have some  soak time in rawhide or
> Debian unstable before enabling it by default  upstream.

I don't think upstream needs to be more conservative than the
development distro's.

--b.

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

[Chuck Lever]

On Jun 5, 2009, at 12:38 PM, J. Bruce Fields wrote:

> On Fri, Jun 05, 2009 at 12:14:48PM -0400, Chuck Lever wrote:
>>
>> On Jun 5, 2009, at 12:10 PM, J. Bruce Fields wrote:
>>
>>> On Fri, Jun 05, 2009 at 07:36:48AM -0400, Jeff Layton wrote:
>>>> Eventually, we most distros are going to want to build nfs-utils
>>>> against libtirpc in order to get IPv6 support. At some point, we'll
>>>> probably want to make building with IPv6 support the default. In  
>>>> the
>>>> meantime however, we need to get more testing exposure for the TI- 
>>>> RPC
>>>> codepaths. We'll probably start building Fedora's nfs-utils with  
>>>> TI-
>>>> RPC
>>>> support in the near future.
>>>>
>>>> The question that Steve D. has asked is whether we should also make
>>>> --enable-tirpc the default for the mainline nfs-utils tree?
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Thoughts?
>>>
>>> Makes sense to me to have upstream defaults set to what we expect
>>> distributions to move to, assuming there aren't known regressions.
>>>
>> That's a big assumption,
>
> I'm confused--there are known regressions or there aren't.  (I'm not
> talking about unknown regressions....)

To say there are or there aren't is a little black and white.

While this TI-RPC implementation has been around for a while, we've  
seen some rather significant bugs in this port.  For example, we've  
seen issues having to do with the width and endianness of basic data  
types; the position of fields in structures shared with the legacy RPC  
implementation; incorrect authentication behavior with AF_LOCAL  
transports; missing parameters when making common RPC calls; and so  
on.  Based on this, I'm expecting more of the same.

Given the maturity of the nfs-utils code and how little we seem to  
know about how people use this stuff, I am hesitant to allow wide use  
even though I don't know of any regressions.

>> and it's exactly why we wanted to have some  soak time in rawhide or
>> Debian unstable before enabling it by default  upstream.
>
> I don't think upstream needs to be more conservative than the
> development distro's.

Perhaps, but my experience so far has been that some distros that do  
not bill themselves as "development" seem to just grab the latest nfs- 
utils whenever they cut a new release.  So I'm a little more cautious  
about making new features default in upstream nfs-utils before they've  
had some shake-down time.

Since distros can still disable TI-RPC support with --disable-tirpc,  
I'm not going to advocate strongly one way or the other.  My main  
interest is in gating the flood of bug reports and user annoyance.

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

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

[Steve Dickson]

J. Bruce Fields wrote:
> On Fri, Jun 05, 2009 at 07:36:48AM -0400, Jeff Layton wrote:
>> Eventually, we most distros are going to want to build nfs-utils
>> against libtirpc in order to get IPv6 support. At some point, we'll
>> probably want to make building with IPv6 support the default. In the
>> meantime however, we need to get more testing exposure for the TI-RPC
>> codepaths. We'll probably start building Fedora's nfs-utils with TI-RPC
>> support in the near future.
>>
>> The question that Steve D. has asked is whether we should also make
>> --enable-tirpc the default for the mainline nfs-utils tree?
>>
>> 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.
>>
>> 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.
>>
>> Thoughts?
> 
> Makes sense to me to have upstream defaults set to what we expect
> distributions to move to, assuming there aren't known regressions.
I have to agree with this... Unstable code is unstable code and has to
be fixed _regardless_ of where it happens to be... Upstream, Rawhide
or Untested... 

My main concern is enabling tirpc by default is forcing other distros 
to incorporate libtirpc into their world which they may or may not want
to do... 

Very recently we've fixed the known licenses issues, and both
Chuck and Jeff have done a ton of work to enable IPv6 using the 
library and finally it does wean us away from the unchangeable 
glibc rpc code... 

But making a decency on it should not be taken lightly... IMHO... 
That's why I wanted the other distro to weigh in before the 
change is made...

steved
 

 
 

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

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 ...

> 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
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Jeff Layton]

On Fri, 5 Jun 2009 12:24:39 -0400
Mike Frysinger <vapier@gentoo.org> 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.

> > 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...

-- 
Jeff Layton <jlayton@redhat.com>

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

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 ;)

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Jeff Layton]

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.

Thanks for the input...

-- 
Jeff Layton <jlayton@redhat.com>

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

[Muntz, Daniel]

 

> -----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.

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.

  -Dan

> 
> Thanks for the input...
> 
> --
> Jeff Layton <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-nfs" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 

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

[Jeff Layton]

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.

-- 
Jeff Layton <jlayton@redhat.com>

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

[Steve Dickson]

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... 

steved.


 


 

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

[Jeff Layton]

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>

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

[Steve Dickson]

Jeff Layton wrote:
> 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.
> 
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.

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

[Chuck Lever]

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@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.
>>
> 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.

> 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.  But it's a  
strange argument, when we have --enable-mount, --enable-nfsv4, and on  
and on.

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

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

[Steve Dickson]

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@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.
>>>
>> 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.

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

[Chuck Lever]

On Jun 8, 2009, at 11:04 AM, Steve Dickson 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@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.
>>>>
>>> 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...

That doesn't make sense to me.  TI-RPC is a feature set that includes  
IPv6 support, not the other way around.

>> 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...

TI-RPC is a feature set that happens to require a library.  Just like  
RPCSEC GSS or blkid, for example.  --enable-tirpc means "we want to  
use TI-RPC features in nfs-utils".  Linking with libtirpc is just a  
side-effect of that.

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

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

[Jeff Layton]

On Mon, 08 Jun 2009 11:04:02 -0400
Steve Dickson <SteveD@redhat.com> 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@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.
> >>>
> >> 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@redhat.com>

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

[Chuck Lever]

On Jun 8, 2009, at 12:41 PM, Jeff Layton wrote:

> On Mon, 08 Jun 2009 11:04:02 -0400
> Steve Dickson <SteveD@redhat.com> 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@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.
>>>>>
>>>> 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.

I really don't understand why having TI-RPC in a library is important  
here.

--enable-tirpc is a feature knob.  Forget that it happens to be in a  
library.  Either nfs-utils supports TI-RPC or it supports legacy RPC.   
The external behavior of nfs-utils changes.

Legacy RPC is in a library too.  It happens to be in a library that is  
included by default, so configure doesn't have to figure out where RPC  
support is and whether it is installed.

What's the difference?

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

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

[Jeff Layton]

On Mon, 8 Jun 2009 12:50:59 -0400
Chuck Lever <chuck.lever@oracle.com> wrote:

> 
> On Jun 8, 2009, at 12:41 PM, Jeff Layton wrote:
> 
> > On Mon, 08 Jun 2009 11:04:02 -0400
> > Steve Dickson <SteveD@redhat.com> 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@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.
> >>>>>
> >>>> 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.
> 
> I really don't understand why having TI-RPC in a library is important  
> here.
> 
> --enable-tirpc is a feature knob.  Forget that it happens to be in a  
> library.  Either nfs-utils supports TI-RPC or it supports legacy RPC.   
> The external behavior of nfs-utils changes.
> 
> Legacy RPC is in a library too.  It happens to be in a library that is  
> included by default, so configure doesn't have to figure out where RPC  
> support is and whether it is installed.
> 
> What's the difference?
> 

Ok, fair enough. The question still stands. Why should we turn off TIRPC
support when we could build it in? At some point we're going to want to
make the switch. Why not now?

-- 
Jeff Layton <jlayton@redhat.com>

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

[Chuck Lever]

On Jun 8, 2009, at 1:00 PM, Jeff Layton wrote:

> On Mon, 8 Jun 2009 12:50:59 -0400
> Chuck Lever <chuck.lever@oracle.com> wrote:
>
>>
>> On Jun 8, 2009, at 12:41 PM, Jeff Layton wrote:
>>
>>> On Mon, 08 Jun 2009 11:04:02 -0400
>>> Steve Dickson <SteveD@redhat.com> 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@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.
>>>>>>>
>>>>>> 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.
>>
>> I really don't understand why having TI-RPC in a library is important
>> here.
>>
>> --enable-tirpc is a feature knob.  Forget that it happens to be in a
>> library.  Either nfs-utils supports TI-RPC or it supports legacy RPC.
>> The external behavior of nfs-utils changes.
>>
>> Legacy RPC is in a library too.  It happens to be in a library that  
>> is
>> included by default, so configure doesn't have to figure out where  
>> RPC
>> support is and whether it is installed.
>>
>> What's the difference?
>>
>
> Ok, fair enough. The question still stands. Why should we turn off  
> TIRPC
> support when we could build it in? At some point we're going to want  
> to
> make the switch. Why not now?

Because TI-RPC support hasn't been widely tested yet, and we don't  
have a complete implementation in nfs-utils atm.  It's really an early  
adopter thing right now; not ready for prime time.

The reason I added --enable-tirpc is to allow distributors to keep it  
turned off as we build TI-RPC support into nfs-utils.  That way, early  
adopters can enable it and try out the pieces that are working, and  
distributors have a better guarantee that when they download and build  
the latest upstream nfs-utils, things will pretty much work with the  
default configure settings.

Since we are not done adding TI-RPC support to nfs-utils, we should  
expect some bugs, and some code churn, as we finish up.  I think we  
want to prevent exposing that risk to distributors to as great an  
extent as possible.

Suppose some serious security bug crops up in nfs-utils.  A  
distribution doesn't want to download and build the latest nfs-utils,  
only to find out that they can't fix the security bug without adding a  
bunch of untested TI-RPC code, or go off on a potentially lengthy  
porting project to get just the bug fix they need.

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

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

[Steve Dickson]

Chuck Lever wrote:
>>
>>>>
>>>>> 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.
> 
> I really don't understand why having TI-RPC in a library is important here.
> 
> --enable-tirpc is a feature knob.  Forget that it happens to be in a
> library.  Either nfs-utils supports TI-RPC or it supports legacy RPC. 
> The external behavior of nfs-utils changes.
> 
> Legacy RPC is in a library too.  It happens to be in a library that is
> included by default, so configure doesn't have to figure out where RPC
> support is and whether it is installed.
> 
> What's the difference?
Following this theory there should have been an --enable-glibc
which obviously misguided... 

All configuration flags define functionality not supporting parts 
of those functionalities.... 

Lets just have an --enable-ipv6/--disable-ipv6 flag and leave it to
the distros as to how they want to deal with it. 

Now with that said, just because --enable-ipv6 is set, does not have 
to mean *all* IPv6 support is there, especially if its not fully baked.
More times that not, pieces of major new features are released in 
multi updates... Maybe in this first IPv6 release only the supporting 
components are enabled (ala libtirpc). In the next release client 
side rpc.statd is enabled and so on... 

Trickling things in a very slow and control pace makes it much easier 
to manage new functionality... IMHO... and having the big hammer
(ala --disable-ipv6) is a comfortable thing when comes to maintaining  
stability...

steved.

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

[Chuck Lever]

On Jun 9, 2009, at 8:06 AM, Steve Dickson wrote:

> Chuck Lever wrote:
>>>
>>>>>
>>>>>> 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.
>>
>> I really don't understand why having TI-RPC in a library is  
>> important here.
>>
>> --enable-tirpc is a feature knob.  Forget that it happens to be in a
>> library.  Either nfs-utils supports TI-RPC or it supports legacy RPC.
>> The external behavior of nfs-utils changes.
>>
>> Legacy RPC is in a library too.  It happens to be in a library that  
>> is
>> included by default, so configure doesn't have to figure out where  
>> RPC
>> support is and whether it is installed.
>>
>> What's the difference?
> Following this theory there should have been an --enable-glibc
> which obviously misguided...
>
> All configuration flags define functionality not supporting parts
> of those functionalities....

That is exactly what --enable-tirpc does.  The fact that it is in a  
separate library is completely incidental.  Either you get the new  
code and new features (such as support for rpcbind v3/v4 and support  
for IPv6) or you get the legacy behavior.

--enable-tirpc does more than look for a library.  It switches in a  
bunch of new code in nfs-utils itself, and enables new features and  
new behavior.

I honestly don't see a distinction between --enable-gss, which adds  
additional features in nfs-utils, but requires an additional library,  
and --enable-tirpc, which adds additional features, but requires an  
additional library.

> Lets just have an --enable-ipv6/--disable-ipv6 flag and leave it to
> the distros as to how they want to deal with it.

We already have a run-time switch for IPv6 support: It's /etc/ 
netconfig.  Of course, that switch is entirely ignored if TI-RPC  
support is not built in.  The point is we don't need the configure  
switch at all: if --disable-tirpc is specified, then no IPv6 support  
is available.  if --enable-tirpc is specified, then IPv6 support is  
possible if there are visible inet6 transports in /etc/netconfig.

> Now with that said, just because --enable-ipv6 is set, does not have
> to mean *all* IPv6 support is there, especially if its not fully  
> baked.
> More times that not, pieces of major new features are released in
> multi updates... Maybe in this first IPv6 release only the supporting
> components are enabled (ala libtirpc). In the next release client
> side rpc.statd is enabled and so on...
>
> Trickling things in a very slow and control pace makes it much easier
> to manage new functionality... IMHO... and having the big hammer
> (ala --disable-ipv6) is a comfortable thing when comes to maintaining
> stability...
>
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs"  
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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

[Steve Dickson]

Chuck Lever wrote:
> 
> On Jun 9, 2009, at 8:06 AM, Steve Dickson wrote:
> 
>> Chuck Lever wrote:
>>>>
>>>>>>
>>>>>>> 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.
>>>
>>> I really don't understand why having TI-RPC in a library is important
>>> here.
>>>
>>> --enable-tirpc is a feature knob.  Forget that it happens to be in a
>>> library.  Either nfs-utils supports TI-RPC or it supports legacy RPC.
>>> The external behavior of nfs-utils changes.
>>>
>>> Legacy RPC is in a library too.  It happens to be in a library that is
>>> included by default, so configure doesn't have to figure out where RPC
>>> support is and whether it is installed.
>>>
>>> What's the difference?
>> Following this theory there should have been an --enable-glibc
>> which obviously misguided...
>>
>> All configuration flags define functionality not supporting parts
>> of those functionalities....
> 
> That is exactly what --enable-tirpc does.  The fact that it is in a
> separate library is completely incidental.  Either you get the new code
> and new features (such as support for rpcbind v3/v4 and support for
> IPv6) or you get the legacy behavior.
> 
> --enable-tirpc does more than look for a library.  It switches in a
> bunch of new code in nfs-utils itself, and enables new features and new
> behavior.
I think this is splitting hairs... my friend... the only reason 
libtirpc is even in the picture is because we need RPC library 
code that had IPv6 support. Remember we (i.e the NFS community) were 
told by the glibc people that under no circumstances would we
be able add IPv6 support to the glibc code. So Bull came up with
the answer of using libtirpc and rpcbind. So libtirpc is a means
to an end... and that end is IPv6 support... 

> 
> I honestly don't see a distinction between --enable-gss, which adds
> additional features in nfs-utils, but requires an additional library,
> and --enable-tirpc, which adds additional features, but requires an
> additional library.
-enable-gss cause two daemon to be build and get installed which
adds the Secure NFS functionality. --enable-tirpc only causes code
paths to change, it add no functionality unless Ipv6 is enabled.
So that's way I think all that is needed is an --enable-ipv6 flag.

steved.

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

[Chuck Lever]

On Jun 9, 2009, at 10:48 AM, Steve Dickson wrote:

> Chuck Lever wrote:
>>
>> On Jun 9, 2009, at 8:06 AM, Steve Dickson wrote:
>>
>>> Chuck Lever wrote:
>>>>>
>>>>>>>
>>>>>>>> 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.
>>>>
>>>> I really don't understand why having TI-RPC in a library is  
>>>> important
>>>> here.
>>>>
>>>> --enable-tirpc is a feature knob.  Forget that it happens to be  
>>>> in a
>>>> library.  Either nfs-utils supports TI-RPC or it supports legacy  
>>>> RPC.
>>>> The external behavior of nfs-utils changes.
>>>>
>>>> Legacy RPC is in a library too.  It happens to be in a library  
>>>> that is
>>>> included by default, so configure doesn't have to figure out  
>>>> where RPC
>>>> support is and whether it is installed.
>>>>
>>>> What's the difference?
>>> Following this theory there should have been an --enable-glibc
>>> which obviously misguided...
>>>
>>> All configuration flags define functionality not supporting parts
>>> of those functionalities....
>>
>> That is exactly what --enable-tirpc does.  The fact that it is in a
>> separate library is completely incidental.  Either you get the new  
>> code
>> and new features (such as support for rpcbind v3/v4 and support for
>> IPv6) or you get the legacy behavior.
>>
>> --enable-tirpc does more than look for a library.  It switches in a
>> bunch of new code in nfs-utils itself, and enables new features and  
>> new
>> behavior.
> I think this is splitting hairs... my friend... the only reason
> libtirpc is even in the picture is because we need RPC library
> code that had IPv6 support. Remember we (i.e the NFS community) were
> told by the glibc people that under no circumstances would we
> be able add IPv6 support to the glibc code. So Bull came up with
> the answer of using libtirpc and rpcbind. So libtirpc is a means
> to an end... and that end is IPv6 support...

I think you are making my argument for me.  The fact that TI-RPC  
support could go into glibc (but hasn't because of politics) suggests  
that --enable-tirpc has nothing to do with a particular library.  It  
is solely a feature knob, just like all the other --enable switches  
in ./configure.

>> I honestly don't see a distinction between --enable-gss, which adds
>> additional features in nfs-utils, but requires an additional library,
>> and --enable-tirpc, which adds additional features, but requires an
>> additional library.
> -enable-gss cause two daemon to be build and get installed which
> adds the Secure NFS functionality. --enable-tirpc only causes code
> paths to change, it add no functionality unless Ipv6 is enabled.

TI-RPC is not just an IPv6 enabler.  It also has interoperability  
implications.  Support for rpcbind v3/v4 has no dependence on IPv6.   
You can use rpcbind v3 or v4 requests over IPv4, for example, which  
provides a significantly richer set of functionality.  One area of non- 
IPv6 interest would be support for registering local services via  
AF_UNIX -- this type of registering is actually authenticated, so it  
is a good security feature.

> So that's way I think all that is needed is an --enable-ipv6 flag.

Actually, the new statd is built only if --enable-tirpc is set.  So,  
yes:  new code _and_ new components are provided if --enable-tirpc is  
set.  TI-RPC is very similar to Secure NFS functionality.  Secure NFS  
provides support for new RPC features known as RPCSEC GSS, and -- 
enable-tirpc provides support for new RPC features known as TI-RPC.   
So again, I don't see any philosophical difference between --enable- 
gss and --enable-tirpc.

However, --enable-ipv6 is unnecessary because we want, and have, run- 
time switches for that support.  We are forced to, because nfs-utils  
has to run on kernels which may or may not support IPv6.

I am continuing to argue this point because getting rid of --enable- 
tirpc will make our jobs a lot harder.  The reason this knob is there  
is to firewall the new code and keep upstream nfs-utils stable as we  
integrate more and more support for TI-RPC.

If we call it --enable-ipv6, many distributions will say "so what, i  
don't need that" and leave it turned off.  We won't get the kind of  
soak time we really need.

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

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

[Steve Dickson]

Chuck Lever wrote:
> 
> I think you are making my argument for me.  The fact that TI-RPC support
> could go into glibc (but hasn't because of politics) suggests that
> --enable-tirpc has nothing to do with a particular library.  It is
> solely a feature knob, just like all the other --enable switches in
> ./configure.
So you agree that --enable-tirpc and --enable-ipv6 are the same thing
since you can't have ipv6 without libtirpc and only reason to
have libtirpc is ipv6...

> 
>>> I honestly don't see a distinction between --enable-gss, which adds
>>> additional features in nfs-utils, but requires an additional library,
>>> and --enable-tirpc, which adds additional features, but requires an
>>> additional library.
>> -enable-gss cause two daemon to be build and get installed which
>> adds the Secure NFS functionality. --enable-tirpc only causes code
>> paths to change, it add no functionality unless Ipv6 is enabled.
> 
> TI-RPC is not just an IPv6 enabler.  It also has interoperability
> implications.  Support for rpcbind v3/v4 has no dependence on IPv6.  You
> can use rpcbind v3 or v4 requests over IPv4, for example, which provides
> a significantly richer set of functionality.  One area of non-IPv6
> interest would be support for registering local services via AF_UNIX --
> this type of registering is actually authenticated, so it is a good
> security feature.
But again, the only reason rpcbind is around is because it has 
IPv6 support. Please believe, I was a bit nervous switch out the 
portmapper since it was a very stable piece of code since it
very rarely changed... 
 
> 
>> So that's way I think all that is needed is an --enable-ipv6 flag.
> 
> Actually, the new statd is built only if --enable-tirpc is set.  So,
> yes:  new code _and_ new components are provided if --enable-tirpc is
> set.  TI-RPC is very similar to Secure NFS functionality.  Secure NFS
> provides support for new RPC features known as RPCSEC GSS, and
> --enable-tirpc provides support for new RPC features known as TI-RPC. 
> So again, I don't see any philosophical difference between --enable-gss
> and --enable-tirpc.
And the only reason statd need to use the new code is for IPv6 
support, true? 

> 
> However, --enable-ipv6 is unnecessary because we want, and have,
> run-time switches for that support.  We are forced to, because nfs-utils
> has to run on kernels which may or may not support IPv6.

> 
> I am continuing to argue this point because getting rid of
> --enable-tirpc will make our jobs a lot harder.  The reason this knob is
> there is to firewall the new code and keep upstream nfs-utils stable as
> we integrate more and more support for TI-RPC.
Understood... And I applaud the effort both you and Jeff are making...

> 
> If we call it --enable-ipv6, many distributions will say "so what, i
> don't need that" and leave it turned off.  We won't get the kind of soak
> time we really need.
And if we call --enable-tirpc they will not know that they are enabling 
IPv6 code in statd, true?

But in the end, I guess I have confidence that the distros will do what is 
best for them... and if they have customers that need this support they 
will enable it. If not, they will not enable it, regardless of what 
upstream does...

steved.

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

[Chuck Lever]

On Jun 9, 2009, at 11:41 AM, Steve Dickson wrote:
> Chuck Lever wrote:
>>
>> I think you are making my argument for me.  The fact that TI-RPC  
>> support
>> could go into glibc (but hasn't because of politics) suggests that
>> --enable-tirpc has nothing to do with a particular library.  It is
>> solely a feature knob, just like all the other --enable switches in
>> ./configure.
> So you agree that --enable-tirpc and --enable-ipv6 are the same thing
> since you can't have ipv6 without libtirpc and only reason to
> have libtirpc is ipv6...

I don't agree that they are the same.  There are other reasons to  
support TI-RPC, even in IPv4-only environments.

TI-RPC was invented to sink as many transport dependencies into the  
library code as possible, so RPC applications don't have to deal with  
the transport layer unless absolutely necessary.  They no longer have  
to worry about port numbers and sockaddrs, and the rest.  So, top  
level TI-RPC client APIs (rpc_call(3t)) take a hostname and an RPC  
program/version/procedure, and server side APIs (rpc_reg(3t)) take an  
RPC program/version, and the library handles all the network details  
for you.

So, TI-RPC is a prerequisite for IPv6, and IPv6 is a _subset_ of the  
features that TI-RPC provides.  But, you can use TI-RPC in  
environments that do not have any IPv6 support whatsoever.  The TI-RPC  
transport switch can be used in much the same way as the kernel's RPC  
transport switch -- new transport capabilities are added to the  
library, and TI-RPC applications now have much less work to do to  
support them.

Specifically in the case of nfs-utils, we are adopting TI-RPC to  
support IPv6.  But, that doesn't make IPv6 and TI-RPC equivalent; it  
makes IPv6 the driver of TI-RPC adoption.  Once TI-RPC support is  
enabled, IPv6 comes for free -- it's actually very little extra work  
to provide IPv6 support once TI-RPC support is available.

If TI-RPC support is not available, then IPv6 support is moot.  If it  
is available, then IPv6 support should be controlled via a run-time  
switch, not via a build-time switch.  Thus, --enable-ipv6 should go  
away.

For example: suppose we add sctp transport capabilities to libtirpc.   
Then, does it make sense to build nfs-utils with --enable-ipv6 to get  
that support?  No, it makes sense to build nfs-utils with --enable- 
tirpc, and then use /etc/netconfig to enable sctp transports for nfs- 
utils, because you'll have to dink around in /etc/netconfig whether we  
use --enable-ipv6 or --enable-tirpc.

>>>> I honestly don't see a distinction between --enable-gss, which adds
>>>> additional features in nfs-utils, but requires an additional  
>>>> library,
>>>> and --enable-tirpc, which adds additional features, but requires an
>>>> additional library.
>>> -enable-gss cause two daemon to be build and get installed which
>>> adds the Secure NFS functionality. --enable-tirpc only causes code
>>> paths to change, it add no functionality unless Ipv6 is enabled.
>>
>> TI-RPC is not just an IPv6 enabler.  It also has interoperability
>> implications.  Support for rpcbind v3/v4 has no dependence on  
>> IPv6.  You
>> can use rpcbind v3 or v4 requests over IPv4, for example, which  
>> provides
>> a significantly richer set of functionality.  One area of non-IPv6
>> interest would be support for registering local services via  
>> AF_UNIX --
>> this type of registering is actually authenticated, so it is a good
>> security feature.
> But again, the only reason rpcbind is around is because it has
> IPv6 support. Please believe, I was a bit nervous switch out the
> portmapper since it was a very stable piece of code since it
> very rarely changed...

rpcbind provides additional features, and supports new versions of the  
rpcbind protocol.  ONE REASON you might want these features is IPv6  
support.  You have more secure local registration, and also a --warm- 
start option, for example; both desirable features.  Neither of those  
have anything to do with IPv6.

>>> So that's way I think all that is needed is an --enable-ipv6 flag.
>>
>> Actually, the new statd is built only if --enable-tirpc is set.  So,
>> yes:  new code _and_ new components are provided if --enable-tirpc is
>> set.  TI-RPC is very similar to Secure NFS functionality.  Secure NFS
>> provides support for new RPC features known as RPCSEC GSS, and
>> --enable-tirpc provides support for new RPC features known as TI-RPC.
>> So again, I don't see any philosophical difference between --enable- 
>> gss
>> and --enable-tirpc.
> And the only reason statd need to use the new code is for IPv6
> support, true?

Yes, but I don't see why that's relevant.  Again, IPv6 may be a driver  
for our adoption of TI-RPC, but that doesn't mean the two are  
equivalent.

>> However, --enable-ipv6 is unnecessary because we want, and have,
>> run-time switches for that support.  We are forced to, because nfs- 
>> utils
>> has to run on kernels which may or may not support IPv6.
>
>> I am continuing to argue this point because getting rid of
>> --enable-tirpc will make our jobs a lot harder.  The reason this  
>> knob is
>> there is to firewall the new code and keep upstream nfs-utils  
>> stable as
>> we integrate more and more support for TI-RPC.
> Understood... And I applaud the effort both you and Jeff are making...
>
>> If we call it --enable-ipv6, many distributions will say "so what, i
>> don't need that" and leave it turned off.  We won't get the kind of  
>> soak
>> time we really need.
> And if we call --enable-tirpc they will not know that they are  
> enabling
> IPv6 code in statd, true?

The new man page for statd explains how that works; inet6 can be  
disabled for statd, if desired, via the run-time switch provided in / 
etc/netconfig.

But even if statd can respond to NSM requests from IPv6, that really  
doesn't matter, unless the rest of the system is ready for IPv6.  It's  
simply a piece of the infrastructure.  AFAICT there is no harm in  
having an IPv6-enabled statd on a system that doesn't otherwise  
support IPv6.

> But in the end, I guess I have confidence that the distros will do  
> what is
> best for them... and if they have customers that need this support  
> they
> will enable it. If not, they will not enable it, regardless of what
> upstream does...

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

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

[Chuck Lever]

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

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

[Mike Frysinger]

On Monday 08 June 2009 10:16:07 Chuck Lever wrote:
> 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.

the automatic fallback is when no tirpc option is specified.  if --enable-
tirpc is specified, then it should fail (and that is what the proposed patch 
does).
-mike

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

[Muntz, Daniel]

 

> -----Original Message-----
> From: Mike Frysinger [mailto:vapier@gentoo.org] 
> Sent: Monday, June 08, 2009 7:24 AM
> To: Chuck Lever
> Cc: Jeff Layton; Muntz, Daniel; linux-nfs@vger.kernel.org
> Subject: Re: should we make --enable-tirpc the default in 
> current nfs-utils?
> 
> On Monday 08 June 2009 10:16:07 Chuck Lever wrote:
> > 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.
> 
> the automatic fallback is when no tirpc option is specified.  
> if --enable- tirpc is specified, then it should fail (and 
> that is what the proposed patch does).
> -mike
> 

When libnfsidmap, libgssglue, etc. are not present the build fails.  The
builder didn't specify any particular --enable-X flag, and the build
doesn't just do something like fall back and build v3-only.  Why would I
want the build to nondeterministically (to the extent that one might not
be aware of what libraries are installed) generate different code?

  -Dan

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

[Jeff Layton]

On Mon, 8 Jun 2009 08:36:34 -0700
"Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:

>  
> 
> > -----Original Message-----
> > From: Mike Frysinger [mailto:vapier@gentoo.org] 
> > Sent: Monday, June 08, 2009 7:24 AM
> > To: Chuck Lever
> > Cc: Jeff Layton; Muntz, Daniel; linux-nfs@vger.kernel.org
> > Subject: Re: should we make --enable-tirpc the default in 
> > current nfs-utils?
> > 
> > On Monday 08 June 2009 10:16:07 Chuck Lever wrote:
> > > 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.
> > 
> > the automatic fallback is when no tirpc option is specified.  
> > if --enable- tirpc is specified, then it should fail (and 
> > that is what the proposed patch does).
> > -mike
> > 
> 
> When libnfsidmap, libgssglue, etc. are not present the build fails.  The
> builder didn't specify any particular --enable-X flag, and the build
> doesn't just do something like fall back and build v3-only.  Why would I
> want the build to nondeterministically (to the extent that one might not
> be aware of what libraries are installed) generate different code?
> 

The build only fails if you have enabled features that require them.
For instance it only requires libgssglue if --enable-gss is on. That
gets turned on by default. You could probably make a case for
turning off the feature of the required libs weren't available, but at
some point autoconf becomes a maze of twisty options and fallbacks.

I suppose the difference here is that there's no real *need* for us to
make configure bail out. The user didn't specify to enable or disable
TIRPC, so presumably they don't care. nfs-utils will still build (and
presumably work) when it's built with or without it.

Again, the question is...is there a legitimate (non-FUD) reason to
avoid building with TIRPC support when the required libs and headers
are installed on the machine?

-- 
Jeff Layton <jlayton@redhat.com>

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

[Steve Dickson]

Jeff Layton wrote:
> On Mon, 8 Jun 2009 08:36:34 -0700
> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
> 
>>  
>>
>>> -----Original Message-----
>>> From: Mike Frysinger [mailto:vapier@gentoo.org] 
>>> Sent: Monday, June 08, 2009 7:24 AM
>>> To: Chuck Lever
>>> Cc: Jeff Layton; Muntz, Daniel; linux-nfs@vger.kernel.org
>>> Subject: Re: should we make --enable-tirpc the default in 
>>> current nfs-utils?
>>>
>>> On Monday 08 June 2009 10:16:07 Chuck Lever wrote:
>>>> 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.
>>> the automatic fallback is when no tirpc option is specified.  
>>> if --enable- tirpc is specified, then it should fail (and 
>>> that is what the proposed patch does).
>>> -mike
>>>
>> When libnfsidmap, libgssglue, etc. are not present the build fails.  The
>> builder didn't specify any particular --enable-X flag, and the build
>> doesn't just do something like fall back and build v3-only.  Why would I
>> want the build to nondeterministically (to the extent that one might not
>> be aware of what libraries are installed) generate different code?
>>
> 
> The build only fails if you have enabled features that require them.
> For instance it only requires libgssglue if --enable-gss is on. That
> gets turned on by default. You could probably make a case for
> turning off the feature of the required libs weren't available, but at
> some point autoconf becomes a maze of twisty options and fallbacks.
> 
I actual I like the fact that if --enable-gss is enabled and the
correct libs are not install, the configuration fails...
I think that's the right thing to do...

steved.

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

[Muntz, Daniel]

 

> -----Original Message-----
> From: Chuck Lever [mailto:chuck.lever@oracle.com] 
> Sent: Monday, June 08, 2009 7:16 AM
> To: Jeff Layton
> Cc: Muntz, Daniel; Mike Frysinger; linux-nfs@vger.kernel.org
> Subject: Re: should we make --enable-tirpc the default in 
> current nfs-utils?
> 
> 
> 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.

It would be nice if RH had a way of testing this with Fedora without
making it the default in the standard nfs-utils package until _after_
testing.  Perhaps nfs-utils has evolved to the point where it could use
a release-candidate model.  Then all distros could pull an RC build if
they want it, while production users could pull the last "stable"
release.

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

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

[Jeff Layton]

On Mon, 8 Jun 2009 08:46:23 -0700
"Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:

> > 
> > 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.  
> 
> It would be nice if RH had a way of testing this with Fedora without
> making it the default in the standard nfs-utils package until _after_
> testing.  Perhaps nfs-utils has evolved to the point where it could use
> a release-candidate model.  Then all distros could pull an RC build if
> they want it, while production users could pull the last "stable"
> release.

This has very little to do with Red Hat. We can enable or disable TIRPC
in our own distros without making this change upstream. The question
here is whether we should make this the default now, or does it make
more sense to wait until everything has been converted to TIRPC, and
had IPv6 support added and *then* enable it.

I believe the latter option will be more disruptive. Phasing support in
slowly makes sense and there's an easy "fix" for people who find they
have problems with it (--disable-tirpc).

-- 
Jeff Layton <jlayton@redhat.com>

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

[Chuck Lever]

On Jun 8, 2009, at 12:59 PM, Jeff Layton wrote:

> On Mon, 8 Jun 2009 08:46:23 -0700
> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
>
>>>
>>> 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.
>>
>> It would be nice if RH had a way of testing this with Fedora without
>> making it the default in the standard nfs-utils package until _after_
>> testing.  Perhaps nfs-utils has evolved to the point where it could  
>> use
>> a release-candidate model.  Then all distros could pull an RC build  
>> if
>> they want it, while production users could pull the last "stable"
>> release.
>
> This has very little to do with Red Hat. We can enable or disable  
> TIRPC
> in our own distros without making this change upstream. The question
> here is whether we should make this the default now, or does it make
> more sense to wait until everything has been converted to TIRPC, and
> had IPv6 support added and *then* enable it.

I disagree.

The question about changing the upstream default came up because I  
asked RH to enable this option in Fedora so we can test first.  Steve  
doesn't want Fedora to enable TI-RPC unless upstream has it enabled by  
default.

So this is _precisely_ about why RH won't enable this in Fedora first.

> I believe the latter option will be more disruptive. Phasing support  
> in
> slowly makes sense and there's an easy "fix" for people who find they
> have problems with it (--disable-tirpc).

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

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

[Jeff Layton]

On Mon, 8 Jun 2009 13:05:26 -0400
Chuck Lever <chuck.lever@oracle.com> wrote:

> 
> On Jun 8, 2009, at 12:59 PM, Jeff Layton wrote:
> 
> > On Mon, 8 Jun 2009 08:46:23 -0700
> > "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
> >
> >>>
> >>> 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.
> >>
> >> It would be nice if RH had a way of testing this with Fedora without
> >> making it the default in the standard nfs-utils package until _after_
> >> testing.  Perhaps nfs-utils has evolved to the point where it could  
> >> use
> >> a release-candidate model.  Then all distros could pull an RC build  
> >> if
> >> they want it, while production users could pull the last "stable"
> >> release.
> >
> > This has very little to do with Red Hat. We can enable or disable  
> > TIRPC
> > in our own distros without making this change upstream. The question
> > here is whether we should make this the default now, or does it make
> > more sense to wait until everything has been converted to TIRPC, and
> > had IPv6 support added and *then* enable it.
> 
> I disagree.
> 
> The question about changing the upstream default came up because I  
> asked RH to enable this option in Fedora so we can test first.  Steve  
> doesn't want Fedora to enable TI-RPC unless upstream has it enabled by  
> default.
> 
> So this is _precisely_ about why RH won't enable this in Fedora first.
> 

Steve asked whether we should also make it the default. He stated that
he would prefer that it was the upstream default first, but didn't NAK
turning it on in fedora if we didn't make it the default there.

So I disagree back :)

The discussion of turning this on in Fedora brought about this question
for upstream, but it's a legitimate question for upstream code
regardless of what happens with Fedora.

> > I believe the latter option will be more disruptive. Phasing support  
> > in
> > slowly makes sense and there's an easy "fix" for people who find they
> > have problems with it (--disable-tirpc).
> 
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com


-- 
Jeff Layton <jlayton@redhat.com>

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

[Chuck Lever]

On Jun 8, 2009, at 1:10 PM, Jeff Layton wrote:

> On Mon, 8 Jun 2009 13:05:26 -0400
> Chuck Lever <chuck.lever@oracle.com> wrote:
>
>>
>> On Jun 8, 2009, at 12:59 PM, Jeff Layton wrote:
>>
>>> On Mon, 8 Jun 2009 08:46:23 -0700
>>> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
>>>
>>>>>
>>>>> 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.
>>>>
>>>> It would be nice if RH had a way of testing this with Fedora  
>>>> without
>>>> making it the default in the standard nfs-utils package until  
>>>> _after_
>>>> testing.  Perhaps nfs-utils has evolved to the point where it could
>>>> use
>>>> a release-candidate model.  Then all distros could pull an RC build
>>>> if
>>>> they want it, while production users could pull the last "stable"
>>>> release.
>>>
>>> This has very little to do with Red Hat. We can enable or disable
>>> TIRPC
>>> in our own distros without making this change upstream. The question
>>> here is whether we should make this the default now, or does it make
>>> more sense to wait until everything has been converted to TIRPC, and
>>> had IPv6 support added and *then* enable it.
>>
>> I disagree.
>>
>> The question about changing the upstream default came up because I
>> asked RH to enable this option in Fedora so we can test first.  Steve
>> doesn't want Fedora to enable TI-RPC unless upstream has it enabled  
>> by
>> default.
>>
>> So this is _precisely_ about why RH won't enable this in Fedora  
>> first.
>
> Steve asked whether we should also make it the default. He stated that
> he would prefer that it was the upstream default first, but didn't NAK
> turning it on in fedora if we didn't make it the default there.
>
> So I disagree back :)
>
> The discussion of turning this on in Fedora brought about this  
> question
> for upstream, but it's a legitimate question for upstream code
> regardless of what happens with Fedora.

I brought this up because this upstream code hasn't had wide enough  
testing.  In my view, enabling TI-RPC in Fedora (or in some other  
development distribution) is a pre-requisite for making it the default  
in upstream.  As Fedora (and perhaps OpenSuSE) is the only  
distribution I'm aware of that has TI-RPC, that's why we might want to  
consider testing there first.

So, to answer your question, IMO enabling TI-RPC upstream now is  
jumping the gun.

>>> I believe the latter option will be more disruptive. Phasing support
>>> in
>>> slowly makes sense and there's an easy "fix" for people who find  
>>> they
>>> have problems with it (--disable-tirpc).

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

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

[Steve Dickson]

Chuck Lever wrote:
> 
> On Jun 8, 2009, at 12:59 PM, Jeff Layton wrote:
> 
>> On Mon, 8 Jun 2009 08:46:23 -0700
>> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
>>
>>>>
>>>> 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.
>>>
>>> It would be nice if RH had a way of testing this with Fedora without
>>> making it the default in the standard nfs-utils package until _after_
>>> testing.  Perhaps nfs-utils has evolved to the point where it could use
>>> a release-candidate model.  Then all distros could pull an RC build if
>>> they want it, while production users could pull the last "stable"
>>> release.
>>
>> This has very little to do with Red Hat. We can enable or disable TIRPC
>> in our own distros without making this change upstream. The question
>> here is whether we should make this the default now, or does it make
>> more sense to wait until everything has been converted to TIRPC, and
>> had IPv6 support added and *then* enable it.
> 
> I disagree.
> 
> The question about changing the upstream default came up because I asked
> RH to enable this option in Fedora so we can test first.  Steve doesn't
> want Fedora to enable TI-RPC unless upstream has it enabled by default.
> 
> So this is _precisely_ about why RH won't enable this in Fedora first.
My concern, as with all package maintainers, is to keep their package
or git tree or whatever as stable as possible so as not to have a 
negative on his or her community users.... 

So my reluctance to make the switch in the Fedora Development stream,
called Rawhide, came from the concern of breaking the NFS components 
what would have (as it has have) a very negative effect on entire 
development of the next release (in this case F-12). 

So I like to "Bake" things in upstream for a while, to see how things
go. Because in the end, the people who are pulling directly from the 
git tree generally have clue and are very easy to work with because 
of their strong understanding of what they are doing...

Once it appears the new functionality somewhat "baked", I will gladly 
introduce the functionality into rawhide, which enables testing by 
a much broader community... which is a very good thing...

I have found that this theory has worked fairly well in the all
the packages I maintain.... Not to say things don't break... Just
ask the Fedora community about the time I broke mount.. My IRC 
window lit up so fast I thought it was on fire! 8-)

So in the end, its not the case I won't enable it, I just want to
take as many precautions as I can to ensure both streams, upstream
and rawhide stay as stable as possible...

steved.

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

[Chuck Lever]

On Jun 9, 2009, at 8:35 AM, Steve Dickson wrote:
> Chuck Lever wrote:
>>
>> On Jun 8, 2009, at 12:59 PM, Jeff Layton wrote:
>>
>>> On Mon, 8 Jun 2009 08:46:23 -0700
>>> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
>>>
>>>>>
>>>>> 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.
>>>>
>>>> It would be nice if RH had a way of testing this with Fedora  
>>>> without
>>>> making it the default in the standard nfs-utils package until  
>>>> _after_
>>>> testing.  Perhaps nfs-utils has evolved to the point where it  
>>>> could use
>>>> a release-candidate model.  Then all distros could pull an RC  
>>>> build if
>>>> they want it, while production users could pull the last "stable"
>>>> release.
>>>
>>> This has very little to do with Red Hat. We can enable or disable  
>>> TIRPC
>>> in our own distros without making this change upstream. The question
>>> here is whether we should make this the default now, or does it make
>>> more sense to wait until everything has been converted to TIRPC, and
>>> had IPv6 support added and *then* enable it.
>>
>> I disagree.
>>
>> The question about changing the upstream default came up because I  
>> asked
>> RH to enable this option in Fedora so we can test first.  Steve  
>> doesn't
>> want Fedora to enable TI-RPC unless upstream has it enabled by  
>> default.
>>
>> So this is _precisely_ about why RH won't enable this in Fedora  
>> first.
> My concern, as with all package maintainers, is to keep their package
> or git tree or whatever as stable as possible so as not to have a
> negative on his or her community users....
>
> So my reluctance to make the switch in the Fedora Development stream,
> called Rawhide, came from the concern of breaking the NFS components
> what would have (as it has have) a very negative effect on entire
> development of the next release (in this case F-12).

There must be something I don't understand.  Why would we foist  
something on all distributions (by placing it in upstream) that you  
wouldn't even put in a development distribution?  My impression was  
that this kind of testing was exactly the purpose of rawhide and  
Fedora.  Is user space NFS special in this regard?  If so, how can we  
make progress if testing opportunities like this are not available to  
user space NFS?

At this point Jeff has convinced me there really aren't any practical  
testing opportunities we can use before this is enabled upstream  
anyway.  So, go ahead and enable TI-RPC by default upstream.  Jeff's  
patch from yesterday seems fine.

> So I like to "Bake" things in upstream for a while, to see how things
> go. Because in the end, the people who are pulling directly from the
> git tree generally have clue and are very easy to work with because
> of their strong understanding of what they are doing...
>
> Once it appears the new functionality somewhat "baked", I will gladly
> introduce the functionality into rawhide, which enables testing by
> a much broader community... which is a very good thing...
>
> I have found that this theory has worked fairly well in the all
> the packages I maintain.... Not to say things don't break... Just
> ask the Fedora community about the time I broke mount.. My IRC
> window lit up so fast I thought it was on fire! 8-)

What this tells me is that our own pre-commit testing of nfs-utils is  
not adequate.  I do not exclude myself from this observation.

> So in the end, its not the case I won't enable it, I just want to
> take as many precautions as I can to ensure both streams, upstream
> and rawhide stay as stable as possible...

Yes, I would also like upstream to be as stable as possible, which is  
why I have voiced a preference for more testing before the existing TI- 
RPC work goes upstream.  The practical world wins out, however.

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

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

[Steve Dickson]

Chuck Lever wrote:
> On Jun 9, 2009, at 8:35 AM, Steve Dickson wrote:
>> Chuck Lever wrote:
>>>
>>> On Jun 8, 2009, at 12:59 PM, Jeff Layton wrote:
>>>
>>>> On Mon, 8 Jun 2009 08:46:23 -0700
>>>> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> It would be nice if RH had a way of testing this with Fedora without
>>>>> making it the default in the standard nfs-utils package until _after_
>>>>> testing.  Perhaps nfs-utils has evolved to the point where it could
>>>>> use
>>>>> a release-candidate model.  Then all distros could pull an RC build if
>>>>> they want it, while production users could pull the last "stable"
>>>>> release.
>>>>
>>>> This has very little to do with Red Hat. We can enable or disable TIRPC
>>>> in our own distros without making this change upstream. The question
>>>> here is whether we should make this the default now, or does it make
>>>> more sense to wait until everything has been converted to TIRPC, and
>>>> had IPv6 support added and *then* enable it.
>>>
>>> I disagree.
>>>
>>> The question about changing the upstream default came up because I asked
>>> RH to enable this option in Fedora so we can test first.  Steve doesn't
>>> want Fedora to enable TI-RPC unless upstream has it enabled by default.
>>>
>>> So this is _precisely_ about why RH won't enable this in Fedora first.
>> My concern, as with all package maintainers, is to keep their package
>> or git tree or whatever as stable as possible so as not to have a
>> negative on his or her community users....
>>
>> So my reluctance to make the switch in the Fedora Development stream,
>> called Rawhide, came from the concern of breaking the NFS components
>> what would have (as it has have) a very negative effect on entire
>> development of the next release (in this case F-12).
> 
> There must be something I don't understand.  Why would we foist
> something on all distributions (by placing it in upstream) that you
> wouldn't even put in a development distribution?  
It comes down to choice... If someone does a git pull and make install
from the upstream git tree and nfs-utils blows up breaking NFS
1) it on them to debug and fix or simply back it out 
2) It only effects them.

When an rawhide (or opensuse) user does a "system update to the latest
untested version" and nfs-utils blows up 
1) its on the package maintainer to (quickly) debug and fix or back out 
2) more importantly it effect the entire community until another 
   build cycle which can take up to 24 to 48 hours.
 
> My impression was that
> this kind of testing was exactly the purpose of rawhide and Fedora.  Is
> user space NFS special in this regard?  If so, how can we make progress
> if testing opportunities like this are not available to user space NFS?
Bug fixes, cleanups and minor enhancements (like enabling nfs41 support in
rpc.nfsd) are what I see development streams are for... But switching 
out an entire supporting library, replacing all the glibc RPC code 
is completely different... IMHO

steved.

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

[Muntz, Daniel]

 

> -----Original Message-----
> From: Jeff Layton [mailto:jlayton@redhat.com] 
> Sent: Monday, June 08, 2009 10:00 AM
> To: Muntz, Daniel
> Cc: Chuck Lever; Mike Frysinger; linux-nfs@vger.kernel.org
> Subject: Re: should we make --enable-tirpc the default in 
> current nfs-utils?
> 
> On Mon, 8 Jun 2009 08:46:23 -0700
> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
> 
> > > 
> > > 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.
> > 
> > It would be nice if RH had a way of testing this with 
> Fedora without 
> > making it the default in the standard nfs-utils package 
> until _after_ 
> > testing.  Perhaps nfs-utils has evolved to the point where it could 
> > use a release-candidate model.  Then all distros could pull an RC 
> > build if they want it, while production users could pull 
> the last "stable"
> > release.
> 
> This has very little to do with Red Hat. We can enable or 
> disable TIRPC in our own distros without making this change 
> upstream. The question here is whether we should make this 
> the default now, or does it make more sense to wait until 
> everything has been converted to TIRPC, and had IPv6 support 
> added and *then* enable it.

But **IF** you had a release candidate model, then you would have a
mechanism for OTHERS to pick up "pre-release" code and get the
additional testing you are after.  Without it, your only option is to
put un/little-tested code into mainline nfs-utils (I am going on your
assertion and Chuck's that this code needs more testing).  I can't see
any reasonable excuse (non-FUD as you say) for not doing things this
way.

> 
> I believe the latter option will be more disruptive. Phasing 
> support in slowly makes sense and there's an easy "fix" for 
> people who find they have problems with it (--disable-tirpc).
> 
> --
> Jeff Layton <jlayton@redhat.com>
> 

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

[Jeff Layton]

On Mon, 8 Jun 2009 15:17:55 -0700
"Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:

>  
> 
> > -----Original Message-----
> > From: Jeff Layton [mailto:jlayton@redhat.com] 
> > Sent: Monday, June 08, 2009 10:00 AM
> > To: Muntz, Daniel
> > Cc: Chuck Lever; Mike Frysinger; linux-nfs@vger.kernel.org
> > Subject: Re: should we make --enable-tirpc the default in 
> > current nfs-utils?
> > 
> > On Mon, 8 Jun 2009 08:46:23 -0700
> > "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
> > 
> > > > 
> > > > 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.
> > > 
> > > It would be nice if RH had a way of testing this with 
> > Fedora without 
> > > making it the default in the standard nfs-utils package 
> > until _after_ 
> > > testing.  Perhaps nfs-utils has evolved to the point where it could 
> > > use a release-candidate model.  Then all distros could pull an RC 
> > > build if they want it, while production users could pull 
> > the last "stable"
> > > release.
> > 
> > This has very little to do with Red Hat. We can enable or 
> > disable TIRPC in our own distros without making this change 
> > upstream. The question here is whether we should make this 
> > the default now, or does it make more sense to wait until 
> > everything has been converted to TIRPC, and had IPv6 support 
> > added and *then* enable it.
> 
> But **IF** you had a release candidate model, then you would have a
> mechanism for OTHERS to pick up "pre-release" code and get the
> additional testing you are after.  Without it, your only option is to
> put un/little-tested code into mainline nfs-utils (I am going on your
> assertion and Chuck's that this code needs more testing).  I can't see
> any reasonable excuse (non-FUD as you say) for not doing things this
> way.
> 

I'm not sure what you're proposing...so you're saying we should cut a
release candidate version and apply nothing but this patch to it to
make --enable-tirpc the default? Or is this more a proposal to change
the nfs-utils release mode in general?

I'm a bit skeptical that that will result in better testing, but I'm
willing to listen to what you're proposing.

When I say that this code needs more testing, I mean exactly that.
Chuck and I have tested it and banged out as many bugs as we can find.
The next step is to get it into more people's hands. This will likely
uncover even more bugs, which we will then fix.

-- 
Jeff Layton <jlayton@redhat.com>

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

[Muntz, Daniel]

 

> -----Original Message-----
> From: Jeff Layton [mailto:jlayton@redhat.com] 
> Sent: Monday, June 08, 2009 4:08 PM
> To: Muntz, Daniel
> Cc: Chuck Lever; Mike Frysinger; linux-nfs@vger.kernel.org
> Subject: Re: should we make --enable-tirpc the default in 
> current nfs-utils?
> 
> On Mon, 8 Jun 2009 15:17:55 -0700
> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
> 
> >  
> > 
> > > -----Original Message-----
> > > From: Jeff Layton [mailto:jlayton@redhat.com]
> > > Sent: Monday, June 08, 2009 10:00 AM
> > > To: Muntz, Daniel
> > > Cc: Chuck Lever; Mike Frysinger; linux-nfs@vger.kernel.org
> > > Subject: Re: should we make --enable-tirpc the default in current 
> > > nfs-utils?
> > > 
> > > On Mon, 8 Jun 2009 08:46:23 -0700
> > > "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
> > > 
> > > > > 
> > > > > 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.
> > > > 
> > > > It would be nice if RH had a way of testing this with
> > > Fedora without
> > > > making it the default in the standard nfs-utils package
> > > until _after_
> > > > testing.  Perhaps nfs-utils has evolved to the point where it 
> > > > could use a release-candidate model.  Then all distros 
> could pull 
> > > > an RC build if they want it, while production users could pull
> > > the last "stable"
> > > > release.
> > > 
> > > This has very little to do with Red Hat. We can enable or disable 
> > > TIRPC in our own distros without making this change upstream. The 
> > > question here is whether we should make this the default now, or 
> > > does it make more sense to wait until everything has been 
> converted 
> > > to TIRPC, and had IPv6 support added and *then* enable it.
> > 
> > But **IF** you had a release candidate model, then you would have a 
> > mechanism for OTHERS to pick up "pre-release" code and get the 
> > additional testing you are after.  Without it, your only 
> option is to 
> > put un/little-tested code into mainline nfs-utils (I am 
> going on your 
> > assertion and Chuck's that this code needs more testing).  
> I can't see 
> > any reasonable excuse (non-FUD as you say) for not doing 
> things this 
> > way.
> > 
> 
> I'm not sure what you're proposing...so you're saying we 
> should cut a release candidate version and apply nothing but 
> this patch to it to make --enable-tirpc the default? Or is 
> this more a proposal to change the nfs-utils release mode in general?
> 
> I'm a bit skeptical that that will result in better testing, 
> but I'm willing to listen to what you're proposing.

Yes, I'm suggesting changing the release model for nfs-utils to be
similar to the kernel.  Do release candidates with new functionality
that can be picked up by anyone for testing (or inclusion in Fedora, or
any other distro that wants to pick up new, but not necessarily stable
functionality), and then declare a stable release after the RC(s)
converge on stability.

Without picking on any particular area, there are a number of things
that come to mind that we might have caught in an RC, that were instead
caught in production environments because there's no distinction between
a stable nfs-utils release and one that needs more testing.

I suppose one could argue that this would result in less testing in the
sense that such a model should make it less likely that testing occurs
in production, however I'll assert that is "good".  Distros like Fedora,
and people who want to run on the bleeding edge (Gentoo) can pull the
latest RC, and testing will occur there.
 
> 
> When I say that this code needs more testing, I mean exactly that.
> Chuck and I have tested it and banged out as many bugs as we can find.
> The next step is to get it into more people's hands. This 
> will likely uncover even more bugs, which we will then fix.
> 
> --
> Jeff Layton <jlayton@redhat.com>
> 

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

[Steve Dickson]

Muntz, Daniel wrote:
>  
> 
>> -----Original Message-----
>> From: Jeff Layton [mailto:jlayton@redhat.com] 
>> Sent: Monday, June 08, 2009 10:00 AM
>> To: Muntz, Daniel
>> Cc: Chuck Lever; Mike Frysinger; linux-nfs@vger.kernel.org
>> Subject: Re: should we make --enable-tirpc the default in 
>> current nfs-utils?
>>
>> On Mon, 8 Jun 2009 08:46:23 -0700
>> "Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
>>
>>>> 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.
>>> It would be nice if RH had a way of testing this with 
>> Fedora without 
>>> making it the default in the standard nfs-utils package 
>> until _after_ 
>>> testing.  Perhaps nfs-utils has evolved to the point where it could 
>>> use a release-candidate model.  Then all distros could pull an RC 
>>> build if they want it, while production users could pull 
>> the last "stable"
>>> release.
>> This has very little to do with Red Hat. We can enable or 
>> disable TIRPC in our own distros without making this change 
>> upstream. The question here is whether we should make this 
>> the default now, or does it make more sense to wait until 
>> everything has been converted to TIRPC, and had IPv6 support 
>> added and *then* enable it.
> 
> But **IF** you had a release candidate model, then you would have a
> mechanism for OTHERS to pick up "pre-release" code and get the
> additional testing you are after.  Without it, your only option is to
> put un/little-tested code into mainline nfs-utils (I am going on your
> assertion and Chuck's that this code needs more testing).  I can't see
> any reasonable excuse (non-FUD as you say) for not doing things this
> way.
> 
hmm.. this is an interesting idea... I do create tags in
the git tree that are a collection of commits... So I guess
those could be come rc releases... but I'm not sure how 
I could package them or even if they should be packaged... 

I guess I could do what I'm doing with the nfs41 and pNFS
code and have development yum reposes, but its an Fedora only
thing so its not clear how useful it would be...

steved.