On Jun 6, 2009, at 4:02 PM, Jeff Layton wrote:
On Sat, 6 Jun 2009 11:00:41 -0700
"Muntz, Daniel" <Dan.Muntz@xxxxxxxxxx> wrote:
-----Original Message-----
From: Jeff Layton [mailto:jlayton@xxxxxxxxxx]
Sent: Saturday, June 06, 2009 4:12 AM
To: Mike Frysinger
Cc: linux-nfs@xxxxxxxxxxxxxxx
Subject: Re: should we make --enable-tirpc the default in
current nfs-utils?
On Fri, 5 Jun 2009 16:50:41 -0400
Mike Frysinger <vapier@xxxxxxxxxx> wrote:
On Friday 05 June 2009 13:36:34 Jeff Layton wrote:
On Fri, 5 Jun 2009 12:24:39 -0400 Mike Frysinger wrote:
On Friday 05 June 2009 07:36:48 Jeff Layton wrote:
Doing this now would add wider testing exposure for these
codepaths and help flush out bugs in TIRPC+IPV4
codepaths. OTOH,
it means adding a new library dependency for packagers, or
they'll need to take the conscious step to
--disable-tirpc when they configure.
or have the configure script dump a warning whenever
libtirpc is
not used ...
The problem there is that these sorts of warnings tend to
get lost
in the noise. So then you have the situation where people aren't
sure whether they built against libtirpc or not. Only running ldd
against the binaries will tell you.
the configure script knows whether it's going to be
building against libtirpc.
it isnt going to happen randomly during `make`.
AC_MSG_WARNING([
You really should think about switching to libtirpc
])
maybe it's different in Gentoo, but people report configure
warnings
all the time ;)
Well, Gentoo probably has a larger percentage of people
compiling the sources. Other distros generally distribute the
binaries. But to be fair, it's not unreasonable to expect
people who are compiling from sources to know what they're doing.
We could make it so that configure looks for libtirpc and if
it's not available, configures the build against legacy RPC
interfaces. I think this is a bad idea however. While
it should
"just work" either way, there are some small behavioral
differences when TIRPC support is built in. I think it's
probably better to make enabling and disabling TIRPC
a conscious step.
i think this is the correct behavior for unspecified configure
flags
In general, yes. In this case though I think it's reasonable to
force people compiling the package without tirpc
installed to take
the conscious step to either install the right libs and
headers, or
to add --disable-tirpc.
I think doing so will lead to a more deterministic
outcome in this
situation. If that's a problem however, I'm willing to
listen to the
reasoning and reconsider...
i just dont agree with having to re-run configure to "fix"
a condition
that the configure script should already be able to handle.
but i'm
speaking in general terms here, not specific to what you propose as
that isnt exactly the same thing. i dont feel too strongly here,
especially since it doesnt affect me in any realistic way.
-mike
Ok, fair enough. I don't feel terribly strongly about this
either and that is the the conventional way that configure
options work (don't fail unless absolutely necessary). I'll
see about coding up a patch that makes --enable-tirpc the
default but falls back to legacy RPC code with a warning if
TIRPC libs/headers aren't present.
Changing the default because the code isn't sufficiently tested
strikes
me as a particularly bad idea. If Red Hat wants more testing,
distribute nfs-utils with TIRPC enabled in Fedora, and _then_
change the
default in nfs-utils after more testing has occurred. Delegating
testing to unsuspecting end-users (especially people who need to
rebuild
in production environments) seems like an ideal way to cause real
problems.
If users have TIRPC installed on their systems, why would we want to
avoid using it? Pieces of this code (mount.nfs, for instance) are
pretty much complete and working. There's no real reason to build
these
apps against legacy RPC now if we can help it.
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
--
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
