Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-qc0-f179.google.com ([209.85.216.179]:35226 "EHLO mail-qc0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932399AbaLLTAn (ORCPT ); Fri, 12 Dec 2014 14:00:43 -0500 Received: by mail-qc0-f179.google.com with SMTP id c9so5878570qcz.38 for ; Fri, 12 Dec 2014 11:00:42 -0800 (PST) Date: Fri, 12 Dec 2014 14:00:39 -0500 From: Jeff Layton To: Trond Myklebust Cc: Linux NFS Mailing List , Thomas Haynes Subject: Re: [PATCH] nfs: guard fs/nfs/internal.h against multiple inclusion Message-ID: <20141212140039.11995450@tlielax.poochiereds.net> In-Reply-To: References: <1418395818-22062-1-git-send-email-jlayton@primarydata.com> <20141212095804.675912b9@tlielax.poochiereds.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-nfs-owner@vger.kernel.org List-ID: On Fri, 12 Dec 2014 13:58:10 -0500 Trond Myklebust wrote: > On Fri, Dec 12, 2014 at 10:50 AM, Trond Myklebust > wrote: > > On Fri, Dec 12, 2014 at 9:58 AM, Jeff Layton wrote: > >> On Fri, 12 Dec 2014 09:50:18 -0500 > >> Jeff Layton wrote: > >> > >>> Signed-off-by: Jeff Layton > >>> Cc: Thomas Haynes > >>> --- > >>> fs/nfs/internal.h | 4 ++++ > >>> 1 file changed, 4 insertions(+) > >>> > >>> diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h > >>> index efaa31c70fbe..ffef459f0b4f 100644 > >>> --- a/fs/nfs/internal.h > >>> +++ b/fs/nfs/internal.h > >>> @@ -1,6 +1,8 @@ > >>> /* > >>> * NFS internal definitions > >>> */ > >>> +#ifndef __FS_NFS_INTERNAL_H > >> > >> Gyah...sorry for the whitespace typo above. Want me to resend with that > >> tab turned into a space? > > > > That's OK. I'll manage somehow :-) > > > >>> +#define __FS_NFS_INTERNAL_H > >>> > >>> #include "nfs4_fs.h" > >>> #include > >>> @@ -629,3 +631,5 @@ static inline u32 nfs_fhandle_hash(const struct nfs_fh *fh) > >>> return 0; > >>> } > >>> #endif > >>> + > >>> +#endif /* __FS_NFS_INTERNAL_H */ > >> > >> > >> -- > >> Jeff Layton > > > > So, having rethought this a little, I think I'd prefer to keep the > current status. Right now, we catch all instances of someone > incorrectly including this file in another header by virtue of the > fact that the duplicate include will cause a compile error. > Fair enough. The problem that we saw with it turns out to be a bug in a different patch under development so it's not really required. Thanks, -- Jeff Layton