Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754628AbXKZH7R (ORCPT ); Mon, 26 Nov 2007 02:59:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752810AbXKZH7G (ORCPT ); Mon, 26 Nov 2007 02:59:06 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:51783 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753033AbXKZH7E (ORCPT ); Mon, 26 Nov 2007 02:59:04 -0500 Date: Sun, 25 Nov 2007 23:58:43 -0800 From: Andrew Morton To: "Ken'ichi Ohmichi" Cc: lkml , kexec-ml Subject: Re: [PATCH 4/5] Fix the configuration dependencies Message-Id: <20071125235843.69440d4a.akpm@linux-foundation.org> In-Reply-To: <473D0170.1060304@mxs.nes.nec.co.jp> References: <473CFE14.3010400@mxs.nes.nec.co.jp> <473D0170.1060304@mxs.nes.nec.co.jp> X-Mailer: Sylpheed 2.4.1 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3166 Lines: 79 On Fri, 16 Nov 2007 11:33:20 +0900 "Ken'ichi Ohmichi" wrote: > > This patch fixes the configuration dependencies in the vmcoreinfo data. > > i386's "node_data" is defined in arch/x86/mm/discontig_32.c, > and x86_64's one is defined in arch/x86/mm/numa_64.c. > They depend on CONFIG_NUMA: > arch/x86/mm/Makefile_32:7 > obj-$(CONFIG_NUMA) += discontig_32.o > arch/x86/mm/Makefile_64:7 > obj-$(CONFIG_NUMA) += numa_64.o > > ia64's "pgdat_list" is defined in arch/ia64/mm/discontig.c, > and it depends on CONFIG_DISCONTIGMEM and CONFIG_SPARSEMEM: > arch/ia64/mm/Makefile:9-10 > obj-$(CONFIG_DISCONTIGMEM) += discontig.o > obj-$(CONFIG_SPARSEMEM) += discontig.o > > ia64's "node_memblk" is defined in arch/ia64/mm/numa.c, > and it depends on CONFIG_NUMA: > arch/ia64/mm/Makefile:8 > obj-$(CONFIG_NUMA) += numa.o > > Signed-off-by: Ken'ichi Ohmichi > --- > diff -rpuN a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c > --- a/arch/ia64/kernel/machine_kexec.c 2007-11-14 15:39:06.000000000 +0900 > +++ b/arch/ia64/kernel/machine_kexec.c 2007-11-14 15:41:41.000000000 +0900 > @@ -129,10 +129,11 @@ void machine_kexec(struct kimage *image) > > void arch_crash_save_vmcoreinfo(void) > { > -#if defined(CONFIG_ARCH_DISCONTIGMEM_ENABLE) && defined(CONFIG_NUMA) > +#if defined(CONFIG_DISCONTIGMEM) || defined(CONFIG_SPARSEMEM) > VMCOREINFO_SYMBOL(pgdat_list); > VMCOREINFO_LENGTH(pgdat_list, MAX_NUMNODES); > - > +#endif > +#ifdef CONFIG_NUMA > VMCOREINFO_SYMBOL(node_memblk); > VMCOREINFO_LENGTH(node_memblk, NR_NODE_MEMBLKS); > VMCOREINFO_STRUCT_SIZE(node_memblk_s); > diff -rpuN a/arch/x86/kernel/machine_kexec_32.c b/arch/x86/kernel/machine_kexec_32.c > --- a/arch/x86/kernel/machine_kexec_32.c 2007-11-14 15:39:19.000000000 +0900 > +++ b/arch/x86/kernel/machine_kexec_32.c 2007-11-14 15:39:33.000000000 +0900 > @@ -151,7 +151,7 @@ NORET_TYPE void machine_kexec(struct kim > > void arch_crash_save_vmcoreinfo(void) > { > -#ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE > +#ifdef CONFIG_NUMA > VMCOREINFO_SYMBOL(node_data); > VMCOREINFO_LENGTH(node_data, MAX_NUMNODES); > #endif > diff -rpuN a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c > --- a/arch/x86/kernel/machine_kexec_64.c 2007-11-14 15:39:19.000000000 +0900 > +++ b/arch/x86/kernel/machine_kexec_64.c 2007-11-14 15:39:33.000000000 +0900 > @@ -235,7 +235,7 @@ void arch_crash_save_vmcoreinfo(void) > { > VMCOREINFO_SYMBOL(init_level4_pgt); > > -#ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE > +#ifdef CONFIG_NUMA > VMCOREINFO_SYMBOL(node_data); > VMCOREINFO_LENGTH(node_data, MAX_NUMNODES); > #endif > _ > x86_64-make-sparsemem-vmemmap-the-default-memory-model-v2.patch removes the `VMCOREINFO_SYMBOL(node_data);' from arch/x86/kernel/machine_kexec_64.c altogether, so I dropped that part of your patch. - 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/