Re: [PATCH][nfs-utils] configuration: Fix a typo in configure.ac

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Mar 01, 2010 at 07:57:28AM -0500, Steve Dickson wrote:
> On 02/22/2010 01:22 PM, J. Bruce Fields wrote:
> > On Sat, Feb 20, 2010 at 03:45:10PM -0800, Trond Myklebust wrote:
> >> From: Trond Myklebust <Trond.Myklebust@netapp.com>
> >>
> >> Fix a typo in commit 6d5ac3fa (nfsd: Disble NFS 4.1 functionality by default).
> > 
> > Better: please just rever 6d5ac3fa and apply
> > http://marc.info/?l=linux-nfs&m=126540028610022&w=2
> The problem I saw with the this patch was it would take 
> a code change to re-enable the 4.1 functional,

Enabling 4.1 will require no code changes to nfs-utils, only to the
kernel.  (But it will require a lot of code changes to nfs-utils, as we
should complete 4.1 support first.)

> verses a
> enabling a configuration flag. Plus, there has been a 
> precedence set of having these types of configuration flags,
> note the enable_nfsv3, enable_nfsv4, so adding a enable_nfsv41
> seem to me made sense...
> 
> > 
> > 	- distributions shouldn't be turning on 4.1 by default yet.
> Its not... If the --enable_nfsv41 is not set, the 4.1 functional is
> off. Having this type of flag enables the distros to enable the
> functionality on development kernels but disable it on stable 

So you want to enable it (for example) in Fedora, but disable it in
RHEL?

I don't think that's a good idea.  If servers running current Fedora
kernels are still around when the client starts trying 4.1 first, then
we'll run into trouble.

--b.

> kernels, without any additional patches. Again to me, its seems
> like the cleanest way to do it... 
> 
> > 	- In addition to the bug Trond found, 6d5ac3fa also
> > 	  inadvertently disables -N4 in the disable_nfsv41 case.
> Fixed...
> 
> steved.