Re: [PATCH] discontigmem support for ia32 NUMA box against 2.4.19pre8

[Christoph Hellwig <hch@infradead.org>]

On Thu, May 09, 2002 at 11:40:03AM -0700, Patricia Gaughen wrote:
>   > Urgg, sourceforge seems to have turned these nice links into some download
>   > selector crap.  I think it's really time to stop using it as it gets worse
>   > all time..
>   > Any chance you could post links directly to one of the mirrors next time?
> 
> Do you want something like this:
> 
> http://prdownloads.sourceforge.net/lse/x86_discontigmem-2.4.19pre8.patch?use_mi
> rror=unc

Seems to have the same problems. The following seems to work nicely for me:

	http://belnet.dl.sourceforge.net/sourceforge/lse/x86_discontigmem-2.4.19pre8.patch

> 
> oh man, and I just added that in to core_ibmnumaq.c :-)
> 
> you're right, the naming was based on alpha's naming scheme, will change it.

Btw, please also do a s/ibmnumaq/numaq/.  Everyone actually reading
the code should know it's from IBM and given that the design actually
originated at Sequent..

>   > Okay, this comes to the next issue, you seem to use CONFIG_DISCONTIGMEM
>   > and CONFIG_X86_DISCONTIGMEM interchangable in arch/i386/* and numa.c in
>   > fact has a big #ifdef CONFIG_X86_DISCONTIGMEM around all of the code.
>   > AFAICS CONFIG_X86_DISCONTIGMEM is really the selector for the bootmem
>   > workarounds and I think it shouldn't be used anywhere else, or even better
>   > replaced by and HAVE_ARCH_BOOTMEM_NODE #define in asm/pgtable.h.
> 
> yes, I agree and that was my intention with CONFIG_X86_DISCONTIGMEM.  I'll fix 
> them.
> 
> Let me make sure I understand what you mean, you're thing that 
> HAVE_ARCH_BOOTMEM_NODE should be turned on in asm/pgtable.h when 
> CONFIG_DISCONTIGMEM is defined?  If that's so, I'll make the change.

For i386, yes.  It looks to me (please correct me that I'm wrong), that
the ifdefs in bootmem.h are to allow architecture-specific versions
of the *_node functions.  This could also be needed by other architectures
and really isn't a config options.  I think because of this such a
feature-define looks more apropinquate to me then a CONFIG_ option.