Re: [RFC] modularization of i386 setup_arch and mem_init in 2.4.18

[Eric W. Biederman]

Dave Jones <[e-mail]> writes:

> On Fri, Mar 08, 2002 at 01:08:18PM -0800, Patricia Gaughen wrote:
>  > 
>  > Hi,
>  > 
>  > I'm currently working on a discontigmem patch for IBM NUMAQ (an ia32 
>  > NUMA box) and want to reuse the standard i386 code as much as
>  > possible.  To achieve this, I've modularized setup_arch() and
>  > mem_init().  This modularization is what the patch that I've included 
>  > in this email contains.
> 
>  As a sidenote (sort of related topic) :
>  An idea being kicked around a little right now is x86 subarch
>  support for 2.5. With so many of the niche x86 spin-offs appearing
>  lately, all fighting for their own piece of various files in
>  arch/i386/kernel/, it may be time to do the same as the ARM folks did,
>  and have..

I will tenatively vote in favor of this kind of action.  There
are a couple of directions to consider.  This is a two dimensional
problem.

Dimension 1.  Different basic hardware architectures. 
  (pc,numaq,visws,voyager)
Dimension 2.  Different firmware implementations.  
  (pcbios,linuxbios,openfirmware,acpi?)

And beyond that it is fairly important to be able to build a generic
kernel.  That works on everything.  You might have to specify a
command line parameter to tell it which arch it is really running on
but it should work. 

must have per motherboard information in your kernel.  Generally life
is much more pleasant if a small handful of things like irq routing
information is provided by the firmware so you only have to code for a
specific hardware device, and not a specific motherboard.  

And even if we get to the point of putting in motherboard specific
code I would suggest it just provide the information like irq routing,
and which superio chips are present and allow a more generic layer to
handle their setup.

Anyway on the multiplexing the firmware score I have just done the
heavy lifting needed so we can put the firmware switching logic 
all in C code.

Eric