From: Jesse Barnes <jbarnes@engr.sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] general config option cleanup
Date: Thu, 09 Sep 2004 01:07:57 +0000 [thread overview]
Message-ID: <200409081807.57695.jbarnes@engr.sgi.com> (raw)
In-Reply-To: <200409081447.38703.jbarnes@engr.sgi.com>
On Wednesday, September 8, 2004 6:02 pm, Ian Wienand wrote:
> On Wed, Sep 08, 2004 at 02:47:38PM -0700, Jesse Barnes wrote:
> > As threatened, here's a patch that unifies the ia64 memory init and
> > memmap codepaths by unconditionalizing the CONFIG_VIRTUAL_MEM_MAP code
> > and making CONFIG_DISCONTIGMEM required. It also allows building with
> > CONFIG_SMP=n and/or CONFIG_NUMA=n.
>
> Two related things I noticed. Firstly, shouldn't the ACPI_NUMA option
> be linked to NUMA (i.e. if you select one, Kconfig selects the other)?
>
> Secondly, trying to build with CONFIG_NUMA and CONFIG_ACPI_NUMA off
> gave errors like
>
> arch/ia64/mm/built-in.o(.init.text+0x3c0): In function `early_nr_cpus_node':
> : undefined reference to `node_cpuid'
>
> arch/ia64/mm/built-in.o(.init.text+0xf71): In function
`call_pernode_memory':
> : undefined reference to `num_node_memblks'
>
> How about moving the definions in question either outside of #ifdef
> CONFIG_ACPI_NUMA in apci.c or adding them to discontig.c (as below).
Hmm... yeah, I knew that would break. The thing is, ia64 NUMA machines all
provide ACPI NUMA tables to describe their NUMAness, so I figured it was
pointless to try and break that up, but I don't really mind either way.
Jesse
prev parent reply other threads:[~2004-09-09 1:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 21:47 [PATCH] general config option cleanup Jesse Barnes
2004-09-08 22:03 ` Matthew Wilcox
2004-09-08 22:10 ` Jesse Barnes
2004-09-08 22:11 ` Luck, Tony
2004-09-09 1:02 ` Ian Wienand
2004-09-09 1:07 ` Jesse Barnes [this message]
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=200409081807.57695.jbarnes@engr.sgi.com \
--to=jbarnes@engr.sgi.com \
--cc=linux-ia64@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.