| Message ID | 1384554636-25330-1-git-send-email-bjschuma@netapp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Nov 15, 2013, at 18:16, Trond Myklebust <trondmy@gmail.com> wrote: > On Fri, 2013-11-15 at 17:30 -0500, Anna Schumaker wrote: >> My recent patch 644aa303: "NFS: Enabling v4.2 should not recompile nfsd >> and lockd" caused build errors when CONFIG_NFS_USE_LEGACY_DNS=y and when >> CONFIG_NFS_V4=n. This patch fixes those errors. >> > > Wait... > > config NFS_USE_LEGACY_DNS > bool "Use the legacy NFS DNS resolver" > depends on NFS_V4 > help > The kernel now provides a method for translating a host name into an > IP address. Select Y here if you would rather use your own DNS > resolver script. > > If unsure, say N > > config NFS_USE_KERNEL_DNS > bool > depends on NFS_V4 && !NFS_USE_LEGACY_DNS > select DNS_RESOLVER > default y > > How can that result in NFS_V4=n && NFS_USE_LEGACY_DNS=y? OK. The problem is resolved using an include of nfs_fs.h in the right spot. Will fix… -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Nov 18, 2013, at 12:50, Anna Schumaker <bjschuma@netapp.com> wrote: > > It's a poorly phrased commit message, actually. I meant that just setting CONFIG_NFS_USE_LEGACY_DNS=y causes build problems, and then setting CONFIG_NFS_V4=n causes a different set of errors. Ah. OK, now I see why you need it. The code in fs/nfs/super.c relies on it when !defined CONFIG_NFS_V4. You also need to move the CONFIG_NFS_V4_SECURITY_LABEL section outside the CONFIG_NFS_V4, since fs/nfs/dir.c and others need the dummy nfs4_label_alloc and nfs4_label_free inline functions (see Stephen Rothwell ’s email). -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/18/2013 01:37 PM, Myklebust, Trond wrote: > > On Nov 18, 2013, at 12:50, Anna Schumaker <bjschuma@netapp.com> wrote: >> >> It's a poorly phrased commit message, actually. I meant that just setting CONFIG_NFS_USE_LEGACY_DNS=y causes build problems, and then setting CONFIG_NFS_V4=n causes a different set of errors. > > Ah. OK, now I see why you need it. The code in fs/nfs/super.c relies on it when !defined CONFIG_NFS_V4. > > You also need to move the CONFIG_NFS_V4_SECURITY_LABEL section outside the CONFIG_NFS_V4, since fs/nfs/dir.c and others need the dummy nfs4_label_alloc and nfs4_label_free inline functions (see Stephen Rothwell > ’s email). Right. I have a patch that moves them to internal.h instead to get around the whole-file #ifdef that's in nfs4_fs.h. Would you prefer me to submit that independently or as a v2 to this patch? As a bonus, I've used Jenkins to compile as many combinations as possible without an error (I probably should have done that the first time, though...) Anna > > > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@netapp.com > www.netapp.com > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Nov 18, 2013, at 13:41, Anna Schumaker <bjschuma@netapp.com> wrote: > On 11/18/2013 01:37 PM, Myklebust, Trond wrote: >> >> On Nov 18, 2013, at 12:50, Anna Schumaker <bjschuma@netapp.com> wrote: >>> >>> It's a poorly phrased commit message, actually. I meant that just setting CONFIG_NFS_USE_LEGACY_DNS=y causes build problems, and then setting CONFIG_NFS_V4=n causes a different set of errors. >> >> Ah. OK, now I see why you need it. The code in fs/nfs/super.c relies on it when !defined CONFIG_NFS_V4. >> >> You also need to move the CONFIG_NFS_V4_SECURITY_LABEL section outside the CONFIG_NFS_V4, since fs/nfs/dir.c and others need the dummy nfs4_label_alloc and nfs4_label_free inline functions (see Stephen Rothwell >> ’s email). > > Right. I have a patch that moves them to internal.h instead to get around the whole-file #ifdef that's in nfs4_fs.h. Would you prefer me to submit that independently or as a v2 to this patch? Please do it as a v2. > As a bonus, I've used Jenkins to compile as many combinations as possible without an error (I probably should have done that the first time, though...) -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h index e916e86..dc1c915 100644 --- a/fs/nfs/nfs4_fs.h +++ b/fs/nfs/nfs4_fs.h @@ -9,21 +9,20 @@ #ifndef __LINUX_FS_NFS_NFS4_FS_H #define __LINUX_FS_NFS_NFS4_FS_H -#if IS_ENABLED(CONFIG_NFS_V4) - -#define NFS4_MAX_LOOP_ON_RECOVER (10) - -#include <linux/seqlock.h> - #if defined(CONFIG_NFS_V4_2) #define NFS4_MAX_MINOR_VERSION 2 -#else -#if defined(CONFIG_NFS_V4_1) +#elif defined(CONFIG_NFS_V4_1) #define NFS4_MAX_MINOR_VERSION 1 #else #define NFS4_MAX_MINOR_VERSION 0 -#endif /* CONFIG_NFS_V4_1 */ -#endif /* CONFIG_NFS_V4_2 */ +#endif + +#if IS_ENABLED(CONFIG_NFS_V4) + +#define NFS4_MAX_LOOP_ON_RECOVER (10) + +#include <linux/seqlock.h> +#include <linux/nfs_fs.h> struct idmap;
My recent patch 644aa303: "NFS: Enabling v4.2 should not recompile nfsd and lockd" caused build errors when CONFIG_NFS_USE_LEGACY_DNS=y and when CONFIG_NFS_V4=n. This patch fixes those errors. Signed-off-by: Anna Schumaker <bjschuma@netapp.com> --- fs/nfs/nfs4_fs.h | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-)