Date: Thu, 20 Dec 2007 10:49:40 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Andi Kleen <ak@suse.de>,
       Thomas Gleixner <tglx@linutronix.de>,
       Glauber de Oliveira Costa <glommer@gmail.com>,
       Jan Beulich <jbeulich@novell.com>
Subject: Re: [PATCH 0/5] x86: another attempt at x86 pagetable unification
Message-ID: <20071220094940.GA14227@elte.hu>
References: <20071219223534.129042140@goop.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20071219223534.129042140@goop.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2026
Lines: 56


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Here's another round of the pagetable unification patches.  I've done 
> a few dozen rounds of randconfig builds on both 32- and 64-bit, so I 
> hope that will prevent compile problems in your test environment.
> 
> I've also boot-tested 64-bit and 32-bit PAE/non-PAE configs (both 
> paravirt and non-paravirt).

i've done a dozen random tests too and it's looking good so far. Nice 
work!

pgtable_32.h and pgtable_64.h still look a tiny bit messy from the 
include file dependencies POV. For example pgtable_32.h:

 #include <asm/processor.h>
 #include <asm/fixmap.h>
 #include <linux/threads.h>
 #include <asm/paravirt.h>

 #include <linux/bitops.h>
 #include <linux/slab.h>
 #include <linux/list.h>
 #include <linux/spinlock.h>

that asm/paravirt.h include is already present in pgtable.h, in a 
somewhat quirky way:

#ifdef CONFIG_PARAVIRT
#include <asm/paravirt.h>
#else  /* !CONFIG_PARAVIRT */

also, most of the:

  scripts/checkpatch.pl --file include/asm-x86/pgtable*.h

complaints are real ones and should be fixed.

would you be interested in cleaning up that stuff once and forever? It 
would be a fine approach if you just tried to quickly push for a "high 
quality" end result in a series of patches and sent that series to me, 
without having tested it fully through - i can figure out whatever build 
breakages and dependencies there still are. So there would be no 
expectation of getting such a cleanup series right in the first (or 
second, or third) attempt, this is spaghetti code that has been 
accumulated up for years. The important thing would be to be careful to 
not introduce runtime breakages accidentally - build breakages due to 
some include file dependency we can sort out just fine. Hm?

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/