2009-10-22 15:59:33

by Boaz Harrosh

[permalink] [raw]
Subject: Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

On 10/22/2009 04:02 PM, Trond Myklebust wrote:
> On Thu, 2009-10-22 at 10:18 +0200, Boaz Harrosh wrote:
>> On 10/22/2009 02:28 AM, Trond Myklebust wrote:
>>> On Wed, 2009-10-21 at 10:14 +0200, Boaz Harrosh wrote:
>>>> An header should be compilation independent, .i.e pull in
>>>> any header who's declarations are directly used by this header.
>>>> And not let users re-include all it's dependencies all over
>>>> again.
>>>>
>>>> [At the end of the day what's the use of a header if it does
>>>> not have more then one user?]
>>>
>>>
>>> The problem with this is that you quickly end up including the same
>>> header files over and over and over again as they get pulled in several
>>> times over by different headers.
>>>
>>>
>>>
>>
>> What is the problem with that?
>>
>> two things:
>> 1. it is unavoidable.
>> 2. That's why we invented the #ifndef FOO_H #define FOO_H for.
>> 3. Look at the current mess, to the point that you don't understand why
>> the code does not compile, you end up just copy-past the include list
>> of that other file, and now actually do end with extra un-needed includes.
>> (Don't believe me look at the last patch as proof).
>> 4. So I add to an header a use of a type that now needs a new include.
>> All my users do not compile any more. What to do? OK I'll include it so
>> not to change all existing users all over again. Now we get a double
>> standard. All headers used before any users, must be carried around.
>> The late comers are escaped.
>> 5. The opposite of 4. An header is no longer needed. Extra header left at all
>> users.
>>
>> It used to be a problem before me and you have begun programing.
>> Since then the cpp looks at it's internal structures and will not re-open.
>> Note that the compiler never sees the second instance, ever.
>>
>> That said we have no choice of the matter. It is a Kernel style guide. I
>> should know because I was banged on the head with it a couple of times.
>> And rightly so.
>>
>> Come on that was a joke right
>> Boaz
>
> No. What I'm saying is that this doesn't have to be an absolute rule.
> The Kernel style guide assumes that everything in 'include/*' is going
> to be exported all around the kernel.
> The problem is that we put a lot of stuff which is private to fs/nfs and
> fs/nfsd in there. Those header files do not have to absolutely follow
> the style guide rule, 'cos we know what is being included before and
> after them...
>

I'm not sure I understand
You are saying that the patches are very good, but only
the rule I stated originally could be relaxed a little with private
headers where we might get lazy, if the effects are very local?

Well, that's not a problem then, right? just that I can relax a bit
if I want.

But I disagree: see 3, 4, 5 above and that last patch I submitted. That patch
is only the beginning. 85% of all source files in nfs/nfsd could receive the
same love. I only done these I touched. Code tends to stay much-much longer
then we spend time on it. Better get it in shape the first time.

> Cheers
> Trond
>

I've now compiled this with x86 allmodeconfig. It should stay in linux-next for a while
to make sure there's no side effects.

Boaz


2009-11-11 14:57:44

by Boaz Harrosh

[permalink] [raw]
Subject: Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

On 11/05/2009 12:09 AM, J. Bruce Fields wrote:
> On Thu, Oct 22, 2009 at 05:59:33PM +0200, Boaz Harrosh wrote:
>
> I'm assuming Trond's objection is just to the patch changelog
> (specifically, to the statement that any header "should be compilation
> independent"), not to these specific changes.
>
> --b.

Ping

Bruce? Trond? whatsup?

Can Benny put these patches in his tree? He said he would be happy to hold
them for a while, but only if they will be eventually accepted into the
tree as a pnfs pre-requisite. Please ACK on these patches?

I have to make all these put-the-includes-back patches to just make the tree
compile.

Boaz

2009-11-11 17:36:22

by J.Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

On Wed, Nov 11, 2009 at 04:57:46PM +0200, Boaz Harrosh wrote:
> On 11/05/2009 12:09 AM, J. Bruce Fields wrote:
> > On Thu, Oct 22, 2009 at 05:59:33PM +0200, Boaz Harrosh wrote:
> >
> > I'm assuming Trond's objection is just to the patch changelog
> > (specifically, to the statement that any header "should be compilation
> > independent"), not to these specific changes.
> >
> > --b.
>
> Ping
>
> Bruce? Trond? whatsup?
>
> Can Benny put these patches in his tree? He said he would be happy to hold
> them for a while, but only if they will be eventually accepted into the
> tree as a pnfs pre-requisite. Please ACK on these patches?
>
> I have to make all these put-the-includes-back patches to just make the tree
> compile.

They're fine by me.

(Can't speak for Trond, but maybe his initial objection would be met
just editing the changelog to replace the absolute "Any header should be
compilation independent" by the particular advantages you saw in this
case.)

--b.

>
> Boaz
>

2009-11-11 17:59:19

by Boaz Harrosh

[permalink] [raw]
Subject: Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

On 11/11/2009 07:36 PM, J. Bruce Fields wrote:
> On Wed, Nov 11, 2009 at 04:57:46PM +0200, Boaz Harrosh wrote:
>> On 11/05/2009 12:09 AM, J. Bruce Fields wrote:
>>> On Thu, Oct 22, 2009 at 05:59:33PM +0200, Boaz Harrosh wrote:
>>>
>>> I'm assuming Trond's objection is just to the patch changelog
>>> (specifically, to the statement that any header "should be compilation
>>> independent"), not to these specific changes.
>>>
>>> --b.
>>
>> Ping
>>
>> Bruce? Trond? whatsup?
>>
>> Can Benny put these patches in his tree? He said he would be happy to hold
>> them for a while, but only if they will be eventually accepted into the
>> tree as a pnfs pre-requisite. Please ACK on these patches?
>>
>> I have to make all these put-the-includes-back patches to just make the tree
>> compile.
>
> They're fine by me.
>
> (Can't speak for Trond, but maybe his initial objection would be met
> just editing the changelog to replace the absolute "Any header should be
> compilation independent" by the particular advantages you saw in this
> case.)
>

I don't see why. Please advise?

"should be compilation independent", from what I understand of the English
language, is suggestive and advisory only. Now, if I was using "must" or
"shall" like the standard do then that would mean a mandatory directive.
But I'm only saying "should" which is like saying: "I suggest", or
"it is recommended". Am I misunderstanding the language?

Any way the commit log is just my saying so, my sign-off it's not the word
of Linux-god, is it?

> --b.
>
>>
>> Boaz
>>

Thanks
Boaz

2009-11-11 18:05:54

by J.Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

On Wed, Nov 11, 2009 at 07:59:21PM +0200, Boaz Harrosh wrote:
> On 11/11/2009 07:36 PM, J. Bruce Fields wrote:
> > On Wed, Nov 11, 2009 at 04:57:46PM +0200, Boaz Harrosh wrote:
> >> On 11/05/2009 12:09 AM, J. Bruce Fields wrote:
> >>> On Thu, Oct 22, 2009 at 05:59:33PM +0200, Boaz Harrosh wrote:
> >>>
> >>> I'm assuming Trond's objection is just to the patch changelog
> >>> (specifically, to the statement that any header "should be compilation
> >>> independent"), not to these specific changes.
> >>>
> >>> --b.
> >>
> >> Ping
> >>
> >> Bruce? Trond? whatsup?
> >>
> >> Can Benny put these patches in his tree? He said he would be happy to hold
> >> them for a while, but only if they will be eventually accepted into the
> >> tree as a pnfs pre-requisite. Please ACK on these patches?
> >>
> >> I have to make all these put-the-includes-back patches to just make the tree
> >> compile.
> >
> > They're fine by me.
> >
> > (Can't speak for Trond, but maybe his initial objection would be met
> > just editing the changelog to replace the absolute "Any header should be
> > compilation independent" by the particular advantages you saw in this
> > case.)
> >
>
> I don't see why. Please advise?
>
> "should be compilation independent", from what I understand of the English
> language, is suggestive and advisory only. Now, if I was using "must" or
> "shall" like the standard do then that would mean a mandatory directive.
> But I'm only saying "should" which is like saying: "I suggest", or
> "it is recommended". Am I misunderstanding the language?
>
> Any way the commit log is just my saying so, my sign-off it's not the word
> of Linux-god, is it?

I really don't care. Do what you think best.

--b.

2009-11-04 22:09:20

by J.Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

On Thu, Oct 22, 2009 at 05:59:33PM +0200, Boaz Harrosh wrote:
> On 10/22/2009 04:02 PM, Trond Myklebust wrote:
> > No. What I'm saying is that this doesn't have to be an absolute rule.
> > The Kernel style guide assumes that everything in 'include/*' is going
> > to be exported all around the kernel.
> > The problem is that we put a lot of stuff which is private to fs/nfs and
> > fs/nfsd in there. Those header files do not have to absolutely follow
> > the style guide rule, 'cos we know what is being included before and
> > after them...
> >
>
> I'm not sure I understand
> You are saying that the patches are very good, but only
> the rule I stated originally could be relaxed a little with private
> headers where we might get lazy, if the effects are very local?
>
> Well, that's not a problem then, right? just that I can relax a bit
> if I want.
>
> But I disagree: see 3, 4, 5 above and that last patch I submitted. That patch
> is only the beginning. 85% of all source files in nfs/nfsd could receive the
> same love. I only done these I touched. Code tends to stay much-much longer
> then we spend time on it. Better get it in shape the first time.

I'm assuming Trond's objection is just to the patch changelog
(specifically, to the statement that any header "should be compilation
independent"), not to these specific changes.

--b.

2009-11-05 08:48:12

by Boaz Harrosh

[permalink] [raw]
Subject: Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

On 11/05/2009 12:09 AM, J. Bruce Fields wrote:
> On Thu, Oct 22, 2009 at 05:59:33PM +0200, Boaz Harrosh wrote:
>> On 10/22/2009 04:02 PM, Trond Myklebust wrote:
>>> No. What I'm saying is that this doesn't have to be an absolute rule.
>>> The Kernel style guide assumes that everything in 'include/*' is going
>>> to be exported all around the kernel.
>>> The problem is that we put a lot of stuff which is private to fs/nfs and
>>> fs/nfsd in there. Those header files do not have to absolutely follow
>>> the style guide rule, 'cos we know what is being included before and
>>> after them...
>>>
>>
>> I'm not sure I understand
>> You are saying that the patches are very good, but only
>> the rule I stated originally could be relaxed a little with private
>> headers where we might get lazy, if the effects are very local?
>>
>> Well, that's not a problem then, right? just that I can relax a bit
>> if I want.
>>
>> But I disagree: see 3, 4, 5 above and that last patch I submitted. That patch
>> is only the beginning. 85% of all source files in nfs/nfsd could receive the
>> same love. I only done these I touched. Code tends to stay much-much longer
>> then we spend time on it. Better get it in shape the first time.
>
> I'm assuming Trond's objection is just to the patch changelog
> (specifically, to the statement that any header "should be compilation
> independent"), not to these specific changes.
>
> --b.

Speaking of which, Bruce I have a question.

There are a few files in include/linux/ that define xdr definitions
these are used by exportfs nfs and nfsd. Some of it gets exposed
to filesystems. With the pNFS tree we are adding lots more of these,
specifically I'm now to move the pnfs_osd_xdr stuff as well, and blocks.

Could I open up a new include/linux/exportfs/ folder and put there any thing
xdr and exportfs related?

What should be the scope of the move, should any include/linux/ common
files used both by nfs & nfsd be moved there?

Thanks
Boaz

2009-11-05 16:33:26

by J.Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

On Thu, Nov 05, 2009 at 10:48:15AM +0200, Boaz Harrosh wrote:
> On 11/05/2009 12:09 AM, J. Bruce Fields wrote:
> > On Thu, Oct 22, 2009 at 05:59:33PM +0200, Boaz Harrosh wrote:
> >> On 10/22/2009 04:02 PM, Trond Myklebust wrote:
> >>> No. What I'm saying is that this doesn't have to be an absolute rule.
> >>> The Kernel style guide assumes that everything in 'include/*' is going
> >>> to be exported all around the kernel.
> >>> The problem is that we put a lot of stuff which is private to fs/nfs and
> >>> fs/nfsd in there. Those header files do not have to absolutely follow
> >>> the style guide rule, 'cos we know what is being included before and
> >>> after them...
> >>>
> >>
> >> I'm not sure I understand
> >> You are saying that the patches are very good, but only
> >> the rule I stated originally could be relaxed a little with private
> >> headers where we might get lazy, if the effects are very local?
> >>
> >> Well, that's not a problem then, right? just that I can relax a bit
> >> if I want.
> >>
> >> But I disagree: see 3, 4, 5 above and that last patch I submitted. That patch
> >> is only the beginning. 85% of all source files in nfs/nfsd could receive the
> >> same love. I only done these I touched. Code tends to stay much-much longer
> >> then we spend time on it. Better get it in shape the first time.
> >
> > I'm assuming Trond's objection is just to the patch changelog
> > (specifically, to the statement that any header "should be compilation
> > independent"), not to these specific changes.
> >
> > --b.
>
> Speaking of which, Bruce I have a question.
>
> There are a few files in include/linux/ that define xdr definitions
> these are used by exportfs nfs and nfsd. Some of it gets exposed
> to filesystems.

Which specifically?

> With the pNFS tree we are adding lots more of these,
> specifically I'm now to move the pnfs_osd_xdr stuff as well, and blocks.
>
> Could I open up a new include/linux/exportfs/ folder and put there any thing
> xdr and exportfs related?

Well, if it's just a few things, maybe include/linux/exportfs.h?

But, sure, makes sense if there's includes that are specific to pNFS and
that wouldn't be needed by any filesystem that included exportfs.h.

> What should be the scope of the move, should any include/linux/ common
> files used both by nfs & nfsd be moved there?

I don't see why we'd want to do that, but maybe I'm missing something.

--b.

2009-11-05 16:41:36

by J.Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

By the way, along the lines of your .h moves, while looking at steved's
export stuff I was reminded again of how much in include/linux/nfsd is
really internal to nfsd, so I'm thinking of committing this.

--b.

>From 0142013a3f49ca296f8880829c67f2afd85b4bfe Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <[email protected]>
Date: Wed, 4 Nov 2009 18:12:35 -0500
Subject: [PATCH] nfsd: make nfsd/vfs.h for common includes

None of this stuff is used outside nfsd, so move it out of the common
linux include directory.

Actually, probably none of the stuff in include/linux/nfsd/nfsd.h really
belongs there, so later we may remove that file entirely.

Signed-off-by: J. Bruce Fields <[email protected]>
---
fs/nfsd/lockd.c | 1 +
fs/nfsd/nfs2acl.c | 1 +
fs/nfsd/nfs3acl.c | 1 +
fs/nfsd/nfs3proc.c | 1 +
fs/nfsd/nfs4proc.c | 1 +
fs/nfsd/nfs4recover.c | 1 +
fs/nfsd/nfs4state.c | 1 +
fs/nfsd/nfs4xdr.c | 1 +
fs/nfsd/nfsfh.c | 1 +
fs/nfsd/nfsproc.c | 1 +
fs/nfsd/nfssvc.c | 1 +
fs/nfsd/vfs.c | 1 +
fs/nfsd/vfs.h | 98 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/nfsd/nfsd.h | 87 +---------------------------------------
14 files changed, 111 insertions(+), 86 deletions(-)
create mode 100644 fs/nfsd/vfs.h

diff --git a/fs/nfsd/lockd.c b/fs/nfsd/lockd.c
index b2786a5..812bc64 100644
--- a/fs/nfsd/lockd.c
+++ b/fs/nfsd/lockd.c
@@ -16,6 +16,7 @@
#include <linux/sunrpc/svc.h>
#include <linux/nfsd/nfsd.h>
#include <linux/lockd/bind.h>
+#include "vfs.h"

#define NFSDDBG_FACILITY NFSDDBG_LOCKD

diff --git a/fs/nfsd/nfs2acl.c b/fs/nfsd/nfs2acl.c
index 4e3219e..5e8ef72 100644
--- a/fs/nfsd/nfs2acl.c
+++ b/fs/nfsd/nfs2acl.c
@@ -14,6 +14,7 @@
#include <linux/nfsd/xdr3.h>
#include <linux/posix_acl.h>
#include <linux/nfsacl.h>
+#include "vfs.h"

#define NFSDDBG_FACILITY NFSDDBG_PROC
#define RETURN_STATUS(st) { resp->status = (st); return (st); }
diff --git a/fs/nfsd/nfs3acl.c b/fs/nfsd/nfs3acl.c
index 9981dbb..354bf0f 100644
--- a/fs/nfsd/nfs3acl.c
+++ b/fs/nfsd/nfs3acl.c
@@ -13,6 +13,7 @@
#include <linux/nfsd/xdr3.h>
#include <linux/posix_acl.h>
#include <linux/nfsacl.h>
+#include "vfs.h"

#define RETURN_STATUS(st) { resp->status = (st); return (st); }

diff --git a/fs/nfsd/nfs3proc.c b/fs/nfsd/nfs3proc.c
index a713c41..1a259d3 100644
--- a/fs/nfsd/nfs3proc.c
+++ b/fs/nfsd/nfs3proc.c
@@ -25,6 +25,7 @@
#include <linux/nfsd/cache.h>
#include <linux/nfsd/xdr3.h>
#include <linux/nfs3.h>
+#include "vfs.h"

#define NFSDDBG_FACILITY NFSDDBG_PROC

diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index bebc0c2..60a93cd 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -48,6 +48,7 @@
#include <linux/nfsd/xdr4.h>
#include <linux/nfs4_acl.h>
#include <linux/sunrpc/gss_api.h>
+#include "vfs.h"

#define NFSDDBG_FACILITY NFSDDBG_PROC

diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c
index b534840..c7a6b24 100644
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@ -47,6 +47,7 @@
#include <linux/crypto.h>
#include <linux/sched.h>
#include <linux/mount.h>
+#include "vfs.h"

#define NFSDDBG_FACILITY NFSDDBG_PROC

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index fcb9817..d3fad54 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -56,6 +56,7 @@
#include <linux/module.h>
#include <linux/sunrpc/svcauth_gss.h>
#include <linux/sunrpc/clnt.h>
+#include "vfs.h"

#define NFSDDBG_FACILITY NFSDDBG_PROC

diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index 0fbd50c..db0fc55 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -57,6 +57,7 @@
#include <linux/nfs4_acl.h>
#include <linux/sunrpc/gss_api.h>
#include <linux/sunrpc/svcauth_gss.h>
+#include "vfs.h"

#define NFSDDBG_FACILITY NFSDDBG_XDR

diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
index 01965b2..d0d8a21 100644
--- a/fs/nfsd/nfsfh.c
+++ b/fs/nfsd/nfsfh.c
@@ -22,6 +22,7 @@
#include <linux/sunrpc/svc.h>
#include <linux/sunrpc/svcauth_gss.h>
#include <linux/nfsd/nfsd.h>
+#include "vfs.h"
#include "auth.h"

#define NFSDDBG_FACILITY NFSDDBG_FH
diff --git a/fs/nfsd/nfsproc.c b/fs/nfsd/nfsproc.c
index c5393d1..6c967e1 100644
--- a/fs/nfsd/nfsproc.c
+++ b/fs/nfsd/nfsproc.c
@@ -24,6 +24,7 @@
#include <linux/nfsd/nfsd.h>
#include <linux/nfsd/cache.h>
#include <linux/nfsd/xdr.h>
+#include "vfs.h"

typedef struct svc_rqst svc_rqst;
typedef struct svc_buf svc_buf;
diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
index 67ea83e..2944b31 100644
--- a/fs/nfsd/nfssvc.c
+++ b/fs/nfsd/nfssvc.c
@@ -35,6 +35,7 @@
#include <linux/lockd/bind.h>
#include <linux/nfsacl.h>
#include <linux/seq_file.h>
+#include "vfs.h"

#define NFSDDBG_FACILITY NFSDDBG_SVC

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 6385739..a7038ed 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -56,6 +56,7 @@
#endif /* CONFIG_NFSD_V4 */
#include <linux/jhash.h>
#include <linux/ima.h>
+#include "vfs.h"

#include <asm/uaccess.h>

diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h
new file mode 100644
index 0000000..b8011fd
--- /dev/null
+++ b/fs/nfsd/vfs.h
@@ -0,0 +1,98 @@
+/*
+ * Copyright (C) 1995-1997 Olaf Kirch <[email protected]>
+ */
+
+#ifndef LINUX_NFSD_VFS_H
+#define LINUX_NFSD_VFS_H
+
+/*
+ * Flags for nfsd_permission
+ */
+#define NFSD_MAY_NOP 0
+#define NFSD_MAY_EXEC 1 /* == MAY_EXEC */
+#define NFSD_MAY_WRITE 2 /* == MAY_WRITE */
+#define NFSD_MAY_READ 4 /* == MAY_READ */
+#define NFSD_MAY_SATTR 8
+#define NFSD_MAY_TRUNC 16
+#define NFSD_MAY_LOCK 32
+#define NFSD_MAY_OWNER_OVERRIDE 64
+#define NFSD_MAY_LOCAL_ACCESS 128 /* IRIX doing local access check on device special file*/
+#define NFSD_MAY_BYPASS_GSS_ON_ROOT 256
+
+#define NFSD_MAY_CREATE (NFSD_MAY_EXEC|NFSD_MAY_WRITE)
+#define NFSD_MAY_REMOVE (NFSD_MAY_EXEC|NFSD_MAY_WRITE|NFSD_MAY_TRUNC)
+
+/*
+ * Callback function for readdir
+ */
+typedef int (*nfsd_dirop_t)(struct inode *, struct dentry *, int, int);
+
+/* nfsd/vfs.c */
+int fh_lock_parent(struct svc_fh *, struct dentry *);
+int nfsd_racache_init(int);
+void nfsd_racache_shutdown(void);
+int nfsd_cross_mnt(struct svc_rqst *rqstp, struct dentry **dpp,
+ struct svc_export **expp);
+__be32 nfsd_lookup(struct svc_rqst *, struct svc_fh *,
+ const char *, unsigned int, struct svc_fh *);
+__be32 nfsd_lookup_dentry(struct svc_rqst *, struct svc_fh *,
+ const char *, unsigned int,
+ struct svc_export **, struct dentry **);
+__be32 nfsd_setattr(struct svc_rqst *, struct svc_fh *,
+ struct iattr *, int, time_t);
+#ifdef CONFIG_NFSD_V4
+__be32 nfsd4_set_nfs4_acl(struct svc_rqst *, struct svc_fh *,
+ struct nfs4_acl *);
+int nfsd4_get_nfs4_acl(struct svc_rqst *, struct dentry *, struct nfs4_acl **);
+#endif /* CONFIG_NFSD_V4 */
+__be32 nfsd_create(struct svc_rqst *, struct svc_fh *,
+ char *name, int len, struct iattr *attrs,
+ int type, dev_t rdev, struct svc_fh *res);
+#ifdef CONFIG_NFSD_V3
+__be32 nfsd_access(struct svc_rqst *, struct svc_fh *, u32 *, u32 *);
+__be32 nfsd_create_v3(struct svc_rqst *, struct svc_fh *,
+ char *name, int len, struct iattr *attrs,
+ struct svc_fh *res, int createmode,
+ u32 *verifier, int *truncp, int *created);
+__be32 nfsd_commit(struct svc_rqst *, struct svc_fh *,
+ loff_t, unsigned long);
+#endif /* CONFIG_NFSD_V3 */
+__be32 nfsd_open(struct svc_rqst *, struct svc_fh *, int,
+ int, struct file **);
+void nfsd_close(struct file *);
+__be32 nfsd_read(struct svc_rqst *, struct svc_fh *, struct file *,
+ loff_t, struct kvec *, int, unsigned long *);
+__be32 nfsd_write(struct svc_rqst *, struct svc_fh *,struct file *,
+ loff_t, struct kvec *,int, unsigned long *, int *);
+__be32 nfsd_readlink(struct svc_rqst *, struct svc_fh *,
+ char *, int *);
+__be32 nfsd_symlink(struct svc_rqst *, struct svc_fh *,
+ char *name, int len, char *path, int plen,
+ struct svc_fh *res, struct iattr *);
+__be32 nfsd_link(struct svc_rqst *, struct svc_fh *,
+ char *, int, struct svc_fh *);
+__be32 nfsd_rename(struct svc_rqst *,
+ struct svc_fh *, char *, int,
+ struct svc_fh *, char *, int);
+__be32 nfsd_remove(struct svc_rqst *,
+ struct svc_fh *, char *, int);
+__be32 nfsd_unlink(struct svc_rqst *, struct svc_fh *, int type,
+ char *name, int len);
+int nfsd_truncate(struct svc_rqst *, struct svc_fh *,
+ unsigned long size);
+__be32 nfsd_readdir(struct svc_rqst *, struct svc_fh *,
+ loff_t *, struct readdir_cd *, filldir_t);
+__be32 nfsd_statfs(struct svc_rqst *, struct svc_fh *,
+ struct kstatfs *, int access);
+
+int nfsd_notify_change(struct inode *, struct iattr *);
+__be32 nfsd_permission(struct svc_rqst *, struct svc_export *,
+ struct dentry *, int);
+int nfsd_sync_dir(struct dentry *dp);
+
+#if defined(CONFIG_NFSD_V2_ACL) || defined(CONFIG_NFSD_V3_ACL)
+struct posix_acl *nfsd_get_posix_acl(struct svc_fh *, int);
+int nfsd_set_posix_acl(struct svc_fh *, int, struct posix_acl *);
+#endif
+
+#endif /* LINUX_NFSD_VFS_H */
diff --git a/include/linux/nfsd/nfsd.h b/include/linux/nfsd/nfsd.h
index 510ffdd..e4518d0 100644
--- a/include/linux/nfsd/nfsd.h
+++ b/include/linux/nfsd/nfsd.h
@@ -25,30 +25,10 @@
*/
#define NFSD_SUPPORTED_MINOR_VERSION 1

-/*
- * Flags for nfsd_permission
- */
-#define NFSD_MAY_NOP 0
-#define NFSD_MAY_EXEC 1 /* == MAY_EXEC */
-#define NFSD_MAY_WRITE 2 /* == MAY_WRITE */
-#define NFSD_MAY_READ 4 /* == MAY_READ */
-#define NFSD_MAY_SATTR 8
-#define NFSD_MAY_TRUNC 16
-#define NFSD_MAY_LOCK 32
-#define NFSD_MAY_OWNER_OVERRIDE 64
-#define NFSD_MAY_LOCAL_ACCESS 128 /* IRIX doing local access check on device special file*/
-#define NFSD_MAY_BYPASS_GSS_ON_ROOT 256
-
-#define NFSD_MAY_CREATE (NFSD_MAY_EXEC|NFSD_MAY_WRITE)
-#define NFSD_MAY_REMOVE (NFSD_MAY_EXEC|NFSD_MAY_WRITE|NFSD_MAY_TRUNC)
-
-/*
- * Callback function for readdir
- */
struct readdir_cd {
__be32 err; /* 0, nfserr, or nfserr_eof */
};
-typedef int (*nfsd_dirop_t)(struct inode *, struct dentry *, int, int);
+

extern struct svc_program nfsd_program;
extern struct svc_version nfsd_version2, nfsd_version3,
@@ -73,69 +53,6 @@ int nfsd_nrpools(void);
int nfsd_get_nrthreads(int n, int *);
int nfsd_set_nrthreads(int n, int *);

-/* nfsd/vfs.c */
-int fh_lock_parent(struct svc_fh *, struct dentry *);
-int nfsd_racache_init(int);
-void nfsd_racache_shutdown(void);
-int nfsd_cross_mnt(struct svc_rqst *rqstp, struct dentry **dpp,
- struct svc_export **expp);
-__be32 nfsd_lookup(struct svc_rqst *, struct svc_fh *,
- const char *, unsigned int, struct svc_fh *);
-__be32 nfsd_lookup_dentry(struct svc_rqst *, struct svc_fh *,
- const char *, unsigned int,
- struct svc_export **, struct dentry **);
-__be32 nfsd_setattr(struct svc_rqst *, struct svc_fh *,
- struct iattr *, int, time_t);
-#ifdef CONFIG_NFSD_V4
-__be32 nfsd4_set_nfs4_acl(struct svc_rqst *, struct svc_fh *,
- struct nfs4_acl *);
-int nfsd4_get_nfs4_acl(struct svc_rqst *, struct dentry *, struct nfs4_acl **);
-#endif /* CONFIG_NFSD_V4 */
-__be32 nfsd_create(struct svc_rqst *, struct svc_fh *,
- char *name, int len, struct iattr *attrs,
- int type, dev_t rdev, struct svc_fh *res);
-#ifdef CONFIG_NFSD_V3
-__be32 nfsd_access(struct svc_rqst *, struct svc_fh *, u32 *, u32 *);
-__be32 nfsd_create_v3(struct svc_rqst *, struct svc_fh *,
- char *name, int len, struct iattr *attrs,
- struct svc_fh *res, int createmode,
- u32 *verifier, int *truncp, int *created);
-__be32 nfsd_commit(struct svc_rqst *, struct svc_fh *,
- loff_t, unsigned long);
-#endif /* CONFIG_NFSD_V3 */
-__be32 nfsd_open(struct svc_rqst *, struct svc_fh *, int,
- int, struct file **);
-void nfsd_close(struct file *);
-__be32 nfsd_read(struct svc_rqst *, struct svc_fh *, struct file *,
- loff_t, struct kvec *, int, unsigned long *);
-__be32 nfsd_write(struct svc_rqst *, struct svc_fh *,struct file *,
- loff_t, struct kvec *,int, unsigned long *, int *);
-__be32 nfsd_readlink(struct svc_rqst *, struct svc_fh *,
- char *, int *);
-__be32 nfsd_symlink(struct svc_rqst *, struct svc_fh *,
- char *name, int len, char *path, int plen,
- struct svc_fh *res, struct iattr *);
-__be32 nfsd_link(struct svc_rqst *, struct svc_fh *,
- char *, int, struct svc_fh *);
-__be32 nfsd_rename(struct svc_rqst *,
- struct svc_fh *, char *, int,
- struct svc_fh *, char *, int);
-__be32 nfsd_remove(struct svc_rqst *,
- struct svc_fh *, char *, int);
-__be32 nfsd_unlink(struct svc_rqst *, struct svc_fh *, int type,
- char *name, int len);
-int nfsd_truncate(struct svc_rqst *, struct svc_fh *,
- unsigned long size);
-__be32 nfsd_readdir(struct svc_rqst *, struct svc_fh *,
- loff_t *, struct readdir_cd *, filldir_t);
-__be32 nfsd_statfs(struct svc_rqst *, struct svc_fh *,
- struct kstatfs *, int access);
-
-int nfsd_notify_change(struct inode *, struct iattr *);
-__be32 nfsd_permission(struct svc_rqst *, struct svc_export *,
- struct dentry *, int);
-int nfsd_sync_dir(struct dentry *dp);
-
#if defined(CONFIG_NFSD_V2_ACL) || defined(CONFIG_NFSD_V3_ACL)
#ifdef CONFIG_NFSD_V2_ACL
extern struct svc_version nfsd_acl_version2;
@@ -147,8 +64,6 @@ extern struct svc_version nfsd_acl_version3;
#else
#define nfsd_acl_version3 NULL
#endif
-struct posix_acl *nfsd_get_posix_acl(struct svc_fh *, int);
-int nfsd_set_posix_acl(struct svc_fh *, int, struct posix_acl *);
#endif

enum vers_op {NFSD_SET, NFSD_CLEAR, NFSD_TEST, NFSD_AVAIL };
--
1.6.3.3


2009-11-05 16:58:58

by Myklebust, Trond

[permalink] [raw]
Subject: Re: [PATCH 2/5] nfsd: Fix independence of a few nfsd related headers

On Thu, 2009-11-05 at 11:41 -0500, J. Bruce Fields wrote:
> By the way, along the lines of your .h moves, while looking at steved's
> export stuff I was reminded again of how much in include/linux/nfsd is
> really internal to nfsd, so I'm thinking of committing this.

Right. Most of the NFS client include files should really be moved into
fs/nfs rather than into a new directory in include/linux.

--
Trond Myklebust
Linux NFS client maintainer

NetApp
[email protected]
http://www.netapp.com