[PATCH V2 08/29] mm: Some arch may want to use HPAGE_PMD related values as variables

[Paul Mackerras]

On Mon, Feb 08, 2016 at 02:50:20PM +0530, Aneesh Kumar K.V wrote:
> With next generation power processor, we are having a new mmu model
> [1] that require us to maintain a different linux page table format.
> 
> Inorder to support both current and future ppc64 systems with a single
> kernel we need to make sure kernel can select between different page
> table format at runtime. With the new MMU (radix MMU) added, we will
> have two different pmd hugepage size 16MB for hash model and 2MB for
> Radix model. Hence make HPAGE_PMD related values as a variable.

But this patch doesn't actually turn any constant into a variable, as
far as I can see...

Most of what this patch does is to move two tests around:

* The #if HPAGE_PMD_ORDER >= MAX_ORDER test get moved from a generic
header into all archs except powerpc, and for powerpc it gets turned
into BUILD_BUG_ON.  However, BUILD_BUG_ON only works on things that
are known at compile time, last time I looked.  Doesn't it need to be
a BUG_ON to prepare for HPAGE_PMD_ORDER being a variable that isn't
known at compile time?

* The existing BUILD_BUG_ON(HPAGE_PMD_ORDER < 2) gets turned into #if
for all archs except powerpc, and for powerpc it stays as a
BUILD_BUG_ON but gets moved to arch code.  That doesn't really seem to
accomplish anything.  Once again, doesn't it need to become a BUG_ON?
If so, could we just make it BUG_ON in the generic code where the
BUILD_BUG_ON currently is?

Paul.