All K8 builds now broken

[Eric W. Biederman]

Greg Watson <gwatson at lanl.gov> writes:

> On 23/03/2004, at 12:50 AM, Eric W. Biederman wrote:
> 
> > Ok I suspect that code came early on and never got cleaned up.
> >
> > What this sounded like was a bug in existing code that caused things to work
> > incorrectly.  So at least on the Opteron things worked correctly.
> >
> > We need to go in and add better cpu selection support in the code.
> > What I am thinking it to extract the vendor and model number for the
> > cpu and with that select the code to run similarly to how we handle
> > other devices.
> >
> > Given the number of small details that need to be verified when a new
> > cpu comes out.  Microcode on the Xeons, memory controller enhancements
> > on the Opterons, etc  I would rather have the build break on a new
> > cpu than have everything just almost work silently.
> >
> >>
> 
> This is probably a good idea, but note that the x86 and ppc architectures do
> things very differently. To start with ppc doesn't have the hierarchical
> arrangement that is used in x86. This leads to a much simpler setup, though it
> does duplicate some code, but in any event I don't want this to change. Also,
> the pre-C configuration is completely different (romcc is not used). However
> this is done, it will need to take these architectural differences into account.

Given that ppc and x86 have different name spaces for cpu identification
we cannot share the implementation.  Like pci and superio devices
similar but different.

What I would like to do is rewrite the architecture specific cpu_initialize 
so that it finds the type of a cpu and the dispatches to code that
is totally cpu specific.  If we have any code reuse it will be by
calling library functions in the cpu specific code.

Once that happens compilation should be reduced to a set of
which basic cpu types do you want to compile support in for.
When cpus made by multiple vendors can share the same socket
that is quite an interesting proposition.

Eric