Re: [GIT PULL] x86: more header untangling

From: Ingo Molnar
Date: Wed Feb 11 2009 - 05:03:51 EST



* Jeremy Fitzhardinge <jeremy@xxxxxxxx> 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
--
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/