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 <[email protected]>
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.
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
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
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.
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
On Fri, 5 Jun 2009 12:24:39 -0400
Mike Frysinger <[email protected]> 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 <[email protected]>
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
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
On Fri, 5 Jun 2009 16:50:41 -0400
Mike Frysinger <[email protected]> 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 <[email protected]>
> -----Original Message-----
> From: Jeff Layton [mailto:[email protected]]
> Sent: Saturday, June 06, 2009 4:12 AM
> To: Mike Frysinger
> Cc: [email protected]
> Subject: Re: should we make --enable-tirpc the default in
> current nfs-utils?
>
> On Fri, 5 Jun 2009 16:50:41 -0400
> Mike Frysinger <[email protected]> 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 <[email protected]>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-nfs" in the body of a message to
> [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
On Sat, 6 Jun 2009 11:00:41 -0700
"Muntz, Daniel" <[email protected]> wrote:
>
>
> > -----Original Message-----
> > From: Jeff Layton [mailto:[email protected]]
> > Sent: Saturday, June 06, 2009 4:12 AM
> > To: Mike Frysinger
> > Cc: [email protected]
> > Subject: Re: should we make --enable-tirpc the default in
> > current nfs-utils?
> >
> > On Fri, 5 Jun 2009 16:50:41 -0400
> > Mike Frysinger <[email protected]> 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 <[email protected]>
Jeff Layton wrote:
> On Sat, 6 Jun 2009 11:00:41 -0700
> "Muntz, Daniel" <[email protected]> wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Jeff Layton [mailto:[email protected]]
>>> Sent: Saturday, June 06, 2009 4:12 AM
>>> To: Mike Frysinger
>>> Cc: [email protected]
>>> Subject: Re: should we make --enable-tirpc the default in
>>> current nfs-utils?
>>>
>>> On Fri, 5 Jun 2009 16:50:41 -0400
>>> Mike Frysinger <[email protected]> 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.
On Mon, 08 Jun 2009 05:09:36 -0400
Steve Dickson <[email protected]> wrote:
>
>
> Jeff Layton wrote:
> > On Sat, 6 Jun 2009 11:00:41 -0700
> > "Muntz, Daniel" <[email protected]> wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jeff Layton [mailto:[email protected]]
> >>> Sent: Saturday, June 06, 2009 4:12 AM
> >>> To: Mike Frysinger
> >>> Cc: [email protected]
> >>> Subject: Re: should we make --enable-tirpc the default in
> >>> current nfs-utils?
> >>>
> >>> On Fri, 5 Jun 2009 16:50:41 -0400
> >>> Mike Frysinger <[email protected]> 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 <[email protected]>