From: Ingo Molnar <mingo@elte.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] x86: more header untangling
Date: Wed, 11 Feb 2009 11:03:23 +0100 [thread overview]
Message-ID: <20090211100323.GE20518@elte.hu> (raw)
In-Reply-To: <4991D626.5040009@goop.org>
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Hi Ingo,
>
> I updated my x86/untangle branch with a merge of tip/x86/headers, which
> needed a couple of little conflict resolutions. Basically this series
> splits out all the simple definitions into -defs.h headers, which in
> turn only have very simple dependencies (either on other -defs.h
> headers, or core generic headers like linux/types.h). It should go some
> way to making it easier to simplify other header's dependencies.
>
> BTW, I've been trying to work out what the real distinction between
> asm/page*.h and asm/pgtable*.h is. pgtable*.h obviously has stuff that
> specifically relates to the details of the page table structures, entry
> formats, bits, and so on, whereas page*.h has more general things like
> page sizes, the layout of the kernel's physical and virtual address
> spaces, etc. So it seems like an anomaly that its page*.h which ends up
> defining all the pte_t/pteval_t/etc types and their associated
> functions. We could move all those into pgtable*.h, but pgtable*.h
> would still depend on page*.h for things like PTE_PFN_MASK, etc, so I
> don't think it would make any practical difference.
The difference is this:
- page*.h is for page frame definitions and general
address space layout details that derive from the page frame.
- pgtable*.h is the pagetable hw format and all things related to it.
Sure, pgtable.h still has to inherit page.h (we cannot talk about a
page table without knowing about a page), but not the other way around.
I.e. the practical difference is not to pgtable.h, but to page.h: we stop
polluting those places with pte_t/pteval_t/etc details that only need
page.h.
I'm sure there will be .c code fallout from moving definitions like this,
but we'll fix those. The previous batch of changes from you stabilized
quickly (we needed only 3 build fixes), so this approach seems to scale
well so far.
So please move those definitions to their logically consistent place and
dont worry about the build fallout.
Another thing:
> arch/x86/include/asm/page-defs.h | 155 ++++++++++++++++++++++
> arch/x86/include/asm/page.h | 146 +--------------------
> arch/x86/include/asm/page_32-defs.h | 92 +++++++++++++
> arch/x86/include/asm/page_32.h | 89 +------------
> arch/x86/include/asm/page_64-defs.h | 105 +++++++++++++++
> arch/x86/include/asm/page_64.h | 101 +--------------
> arch/x86/include/asm/paravirt.h | 2 +-
> arch/x86/include/asm/pgtable-defs.h | 227 +++++++++++++++++++++++++++++++
> arch/x86/include/asm/pgtable.h | 228 +-------------------------------
> arch/x86/include/asm/pgtable_32-defs.h | 46 +++++++
> arch/x86/include/asm/pgtable_32.h | 42 +------
> arch/x86/include/asm/pgtable_64-defs.h | 46 +++++++
> arch/x86/include/asm/pgtable_64.h | 48 +-------
> 13 files changed, 688 insertions(+), 639 deletions(-)
The splitup looks good (sans the comment above), but could you please name
them page_types.h, pgtable_types.h, like we did it for other, cleaned up
headers like spinlock_types.h?
Ingo
next prev parent reply other threads:[~2009-02-11 10:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-10 19:31 [GIT PULL] x86: more header untangling Jeremy Fitzhardinge
2009-02-11 10:03 ` Ingo Molnar [this message]
2009-02-11 17:01 ` Jeremy Fitzhardinge
2009-02-11 17:14 ` Ingo Molnar
2009-02-11 18:55 ` Jeremy Fitzhardinge
2009-02-11 19:47 ` Ingo Molnar
2009-02-11 22:34 ` Jeremy Fitzhardinge
2009-02-13 11:47 ` Ingo Molnar
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=20090211100323.GE20518@elte.hu \
--to=mingo@elte.hu \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox