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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html