From: Roman Zippel <zippel@linux-m68k.org> To: Dave Hansen <haveblue@us.ibm.com> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, geert@linux-m68k.org, ralf@linux-mips.org, linux-mm <linux-mm@kvack.org> Subject: Re: [patch] [RFC] make WANT_PAGE_VIRTUAL a config option Date: Fri, 17 Dec 2004 21:27:10 +0100 (CET) [thread overview] Message-ID: <Pine.LNX.4.61.0412171818090.793@scrub.home> (raw) In-Reply-To: <1103299179.13614.3551.camel@localhost> 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 <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 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
WARNING: multiple messages have this Message-ID (diff)
From: Roman Zippel <zippel@linux-m68k.org> To: Dave Hansen <haveblue@us.ibm.com> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, geert@linux-m68k.org, ralf@linux-mips.org, linux-mm <linux-mm@kvack.org> Subject: Re: [patch] [RFC] make WANT_PAGE_VIRTUAL a config option Date: Fri, 17 Dec 2004 21:27:10 +0100 (CET) [thread overview] Message-ID: <Pine.LNX.4.61.0412171818090.793@scrub.home> (raw) In-Reply-To: <1103299179.13614.3551.camel@localhost> 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 <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 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: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-12-17 20:27 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-12-16 21:56 [patch] [RFC] make WANT_PAGE_VIRTUAL a config option Dave Hansen 2004-12-16 21:56 ` Dave Hansen 2004-12-17 0:36 ` Roman Zippel 2004-12-17 0:36 ` Roman Zippel 2004-12-17 0:42 ` Dave Hansen 2004-12-17 0:42 ` Dave Hansen 2004-12-17 0:51 ` Roman Zippel 2004-12-17 0:51 ` Roman Zippel 2004-12-17 1:14 ` Dave Hansen 2004-12-17 1:14 ` Dave Hansen 2004-12-17 2:50 ` Roman Zippel 2004-12-17 2:50 ` Roman Zippel 2004-12-17 4:24 ` Dave Hansen 2004-12-17 4:24 ` Dave Hansen 2004-12-17 13:26 ` Roman Zippel 2004-12-17 13:26 ` Roman Zippel 2004-12-17 15:59 ` Dave Hansen 2004-12-17 15:59 ` Dave Hansen 2004-12-17 20:27 ` Roman Zippel [this message] 2004-12-17 20:27 ` Roman Zippel 2004-12-17 21:48 ` Dave Hansen 2004-12-17 21:48 ` Dave Hansen 2004-12-18 0:52 ` Roman Zippel 2004-12-18 0:52 ` Roman Zippel 2004-12-20 14:49 ` Dave Hansen 2004-12-20 14:49 ` Dave Hansen 2004-12-20 20:45 ` Roman Zippel 2004-12-20 20:45 ` Roman Zippel 2004-12-17 2:01 ` Dave Hansen 2004-12-17 2:01 ` Dave Hansen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.4.61.0412171818090.793@scrub.home \ --to=zippel@linux-m68k.org \ --cc=geert@linux-m68k.org \ --cc=haveblue@us.ibm.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=ralf@linux-mips.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.