Greg Watson gwatson@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