Re: [patch] [RFC] make WANT_PAGE_VIRTUAL a config option
From: Roman Zippel
Date: Fri Dec 17 2004 - 15:29:08 EST
On Fri, 17 Dec 2004, Dave Hansen wrote:
> That said, it doesn't appear that asm/page.h is a header that causes any
> real problems. In any case, when there are variables that need to be
> created based on Kconfig parameters, I believe the "correct" thing to do
> is make a Kconfig variable. But, that is a separate conversation. :)
Well, that's ok (but maybe give it a better name, e.g.
> > 2) Does every structure really needs its own header?
> No. But, I do think that most of the very basic VM structures do, as it
> stands. That's limited to struct page, zone, and pgdat as I see it
Why do you want to put these into separate headers? These would be AFAICT
good candidates to pull into a single header. Via linux/gfp.h they are
all pulled into a lot of files, so it doesn't make sense to split them
because they may have different users.
> One thing I'd like to point out is that I don't necessarily think that
> the normal foo.c user should see any change. They can still include
> mmzone.h for the same stuff, but *inside* the headers, there's some more
> organization. Here's an example from a new header that I'm working on
> after shifting the headers around.
> #include <asm/page-consts.h> /* for PAGE_SHIFT */
> #include <asm/addr-convert.h> /* for __pa() */
> #include <linux/structpage.h> /* for struct page */
> #include <linux/sparse-consts.h> /* for NR_MEM_SECTIONS... */
> #include <linux/sparse-structs.h> /* for mem_section */
Why do you want to separate constants and structures?
There only relatively few users of mmzone.h, so fixing them is easy and
the main problem with mmzone.h are the macros in asm/mmzone.h, which
should be pulled into a different header and the few remaining definitions
could be also merged with other definitions (is there really a good
reason for a separate asm/numnodes.h or linux/numa.h?).
> The dependencies aren't very twisted at all. In fact, I don't think any
> of those are deeper than two. More importantly, I never have to cope
> with 'struct page;' keeping me from doing arithmetic.
You may be surprised. :)
Play around with "mkdir test; echo 'obj-y = test.o' > test/Makefile; echo
'#include <linux/foo.h>' > test/test.c; make test/test.i
> I agree that I'm probably getting a bit carried away. But, I don't
> really see the harm in having both high-level headers and more finely
> grained ones. You could even think of the finely grained ones as
> internal only.
Well, I don't really like lots of mini header files. I think it's more
important to collect related information and only strictly separate
between definitions and users, when a header gets to large we can still
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/