From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 17 Dec 2004 21:27:10 +0100 (CET) From: Roman Zippel Subject: Re: [patch] [RFC] make WANT_PAGE_VIRTUAL a config option In-Reply-To: <1103299179.13614.3551.camel@localhost> Message-ID: References: <1103244171.13614.2525.camel@localhost> <1103246050.13614.2571.camel@localhost> <1103257482.13614.2817.camel@localhost> <1103299179.13614.3551.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Dave Hansen Cc: Linux Kernel Mailing List , geert@linux-m68k.org, ralf@linux-mips.org, linux-mm List-ID: Hi, 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. CONFIG_PAGE_VIRTUAL_PTR?) > > 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 > now. 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 /* for PAGE_SHIFT */ > #include /* for __pa() */ > #include /* for struct page */ > #include /* for NR_MEM_SECTIONS... */ > #include /* 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 ' > test/test.c; make test/test.i CFLAGS_test.o=--trace-includes". > 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 split it. bye, Roman -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: aart@kvack.org