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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
