public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] mount.nfs: Don't fail mounts when /etc/netconfig is nonexistent
Date: Wed, 27 Jan 2010 13:42:13 -0500	[thread overview]
Message-ID: <4B608905.90708@RedHat.com> (raw)
In-Reply-To: <4B60816E.5070108@oracle.com>

On 01/27/2010 01:09 PM, Chuck Lever wrote:
>> Author: Steve Dickson<steved@redhat.com>
>> Date:   Wed Jan 27 11:19:00 2010 -0500
>>
>>      In a very sparse environments certain system files (like
>>      /etc/netconfig) may not exist. In these environments don't
>>      fail mount if all the need information (like network protocols)
>>      exist and are well known.
>>
>>      Signed-off-by: Steve Dickson<steved@redhat.com>
> 
> I totally disagree with this.  If HAVE_LIBTIRPC is set, then the runtime
> TI-RPC package should be installed, in its entirety, on the run-time
> systems.  If autoconf and RPM can't trust the given dependency
> information, then all bets are off.
Well in some environments "all bets are off" is just not good enough...
Mount has always worked in these type of  environments before and 
I think we should continue to... 

> 
> The right fix is to either:
> 
> a) install a non-TI-RPC version of mount.nfs, or
> 
> b) make sure /etc/netconfig is available when RPM, pkgconfig, and
> autoconf say it should be.
> 
Sparse environments generally have a finite amount of space, that
is simple unchangeable... so the above "luxuries" are simply not 
available...

> 
> I assume since you are not patching other parts of mount.nfs that look
> for /etc/rpc and /etc/protocols that these files _do_ exist?  Or does
> glibc also do this hack of filling in well-known values?
> 
Lets keep this in perspective... the "well-known" values in this patch
things like TCP and UDP... when protocol == IPPROTO_TCP the well known value
is "tcp" (or "tcp6" depending on the family)... Values that have not 
changed for years and will not change for years... 

On the umount side, the file should not be consulted in the first place
since all the information needed in /etc/mtab... Of course things
can change between mount and umounts but I truly do no think the
meaning of "udp" will change from being IPPROTO_UDP....

Making mount more bullet proof and allowing it (continue to) work in all 
different types of environments is a good thing... imho...

steved.


  reply	other threads:[~2010-01-27 18:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-27 16:41 [PATCH] mount.nfs: Don't fail mounts when /etc/netconfig is nonexistent Steve Dickson
2010-01-27 18:09 ` Chuck Lever
2010-01-27 18:42   ` Steve Dickson [this message]
2010-01-27 20:57     ` Chuck Lever
2010-01-27 22:30       ` Peter Staubach
2010-01-28  3:20         ` J. Bruce Fields
2010-01-28 16:05         ` Chuck Lever
2010-01-28 16:36         ` Chuck Lever
2010-01-28 15:39       ` Steve Dickson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B608905.90708@RedHat.com \
    --to=steved@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox