x86 cpu selection (first hack)
PATCH 1/1 x86 cpu selection (first hack)
Hi all.
After reading all the posts in the lista about this and thinking a bit, here is the first attempt (just a try of the general aspect) of a new cpu selection scheme. This post is mainly to see if I really understood the scenario.
There were two ways to do this:
- Define a min/max cpu selecion. Both are a kbuild's 'choice'.
Problems: it generates a ton of symbols of the kind of CPU_MIN_INTEL_PENTIUM or CPU_MAX_AMD_ATHLON. And you have to limit the 'max' choice to be bigger than the first. This brings two problems: limiting the choices on a 'choice' based on one other, and defining an 'order' in processors, even between architectures.
- Make all and every cpu a checkbox, so you just say 'I want my kernel to support this and that CPU'. This kills the problem of the ordering, and adds one other advantage: you do not need to support intermediate CPUs, like 'i want my kernel to run ok on pentium-mmx (my firewall) and on p4 (my desktop). I will never run it on a PII, so do not include the hacks for PII'. And of course, 'If I run my p-mmx capable on a friend's PII and it eats his drive and burns his TV set, it is only _my_ fault'.
Patch follows, comments are welcome. Next step is to begin to order the logic, but I wanted to ask first about this.
arch/i386/config.in +7 -0
@@ -26,6 +26,12 @@ mainmenu_option next_comment comment 'Processor type and features' +bool 'New CPU selection scheme' CONFIG_CPU_SELECTION_NEW + +# CPUConfig +if [ "$CONFIG_CPU_SELECTION_NEW" = "y" ]; then + source arch/i386/CPUConfig.in +else choice 'Processor family' \ "386 CONFIG_M386 \ 486 CONFIG_M486 \
@@ -163,6 +169,7 @@ define_bool CONFIG_X86_USE_PPRO_CHECKSUM y define_bool CONFIG_X86_OOSTORE y fi +fi bool 'Machine Check Exception' CONFIG_X86_MCE
arch/i386/CPUConfig.in +40 -0
@@ -0,0 +1,40 @@ +mainmenu_option next_comment +comment 'CPU selection' + +comment 'Generic x86 CPUs' +bool 'Generic support' CONFIG_VENDOR_GENERIC +if [ "$CONFIG_VENDOR_GENERIC" = "y" ]; then + + bool '386' CONFIG_CPU_GENERIC_386 + bool '486' CONFIG_CPU_GENERIC_486 + bool '586' CONFIG_CPU_GENERIC_586 + bool '686' CONFIG_CPU_GENERIC_686 + +else + +comment 'Intel CPUs' +bool 'Intel support' CONFIG_VENDOR_INTEL +if [ "$CONFIG_VENDOR_INTEL" = "y" ]; then + bool '386' CONFIG_CPU_INTEL_386 + bool '486' CONFIG_CPU_INTEL_486 + bool 'Pentium' CONFIG_CPU_INTEL_PENTIUM + bool 'PentiumMMX' CONFIG_CPU_INTEL_PENTIUMMMX + bool 'PentiumPro' CONFIG_CPU_INTEL_PENTIUMPRO + bool 'PentiumII/Celeron' CONFIG_CPU_INTEL_PENTIUM2 + bool 'PentiumIII/Celeron(Coppermine)' CONFIG_CPU_INTEL_PENTIUM3 + bool 'Pentium4' CONFIG_CPU_INTEL_PENTIUM4 +fi +comment 'AMD CPUs' +bool 'AMD support' CONFIG_VENDOR_AMD +if [ "$CONFIG_VENDOR_AMD" = "y" ]; then + bool '386' CONFIG_CPU_AMD_386 + bool '486' CONFIG_CPU_AMD_486 + bool 'K5' CONFIG_CPU_AMD_K5 + bool 'K6/K6II/K6III' CONFIG_CPU_AMD_K6 + bool 'K7' CONFIG_CPU_AMD_K7 + bool 'Athlon/Duron' CONFIG_CPU_AMD_ATHLON +fi + +fi + +endmenu
Signature · 4 lines
J.A. Magallon # Let the source be with you... mailto:[email protected] Mandrake Linux release 8.3 (Cooker) for i586 Linux werewolf 2.4.19-pre9-jam1 #1 SMP jue may 30 00:48:49 CEST 2002 i686
Quoted 7 lines · J.A. Magallon
- Make all and every cpu a checkbox, so you just say 'I want my kernel to support this and that CPU'. This kills the problem of the ordering, and adds one other advantage: you do not need to support intermediate CPUs, like 'i want my kernel to run ok on pentium-mmx (my firewall) and on p4 (my desktop). I will never run it on a PII, so do not include the hacks for PII'. And of course, 'If I run my p-mmx capable on a friend's PII and it eats his drive and burns his TV set, it is only _my_ fault'.
How about
'Omit support for processors without an FPU'
'Omit support for processors without working WP (386, Nexgen)' 'Require the processor has a TSC'
type questions ?
Quoted 9 lines · On 2002.05.31 Alan Cox wrote:
Quoted 7 lines · J.A. Magallon
- Make all and every cpu a checkbox, so you just say 'I want my kernel to support this and that CPU'. This kills the problem of the ordering, and adds one other advantage: you do not need to support intermediate CPUs, like 'i want my kernel to run ok on pentium-mmx (my firewall) and on p4 (my desktop). I will never run it on a PII, so do not include the hacks for PII'. And of course, 'If I run my p-mmx capable on a friend's PII and it eats his drive and burns his TV set, it is only _my_ fault'.
Quoted 8 lines
How about
'Omit support for processors without an FPU'
'Omit support for processors without working WP (386, Nexgen)' 'Require the processor has a TSC'type questions ?
But that requires people to know many hardware details... How the h**l do I know if my Transmeta or Cyrix or AMD has a TSC ?? Is that an intel specific thing or x86 ?? I just want a kernel that
runs on my XXX brand 586. What is a TSC ??
I think it has to be done based on brand/model.
Signature · 4 lines
J.A. Magallon # Let the source be with you... mailto:[email protected] Mandrake Linux release 8.3 (Cooker) for i586 Linux werewolf 2.4.19-pre9-jam1 #1 SMP jue may 30 00:48:49 CEST 2002 i686
Quoted 8 lines · J.A. Magallon
- Make all and every cpu a checkbox, so you just say 'I want my kernel to support this and that CPU'. This kills the problem of the ordering, and adds one other advantage: you do not need to support intermediate CPUs, like 'i want my kernel to run ok on pentium-mmx (my firewall) and on p4 (my desktop). I will never run it on a PII, so do not include the hacks for PII'. And of course, 'If I run my p-mmx capable on a friend's PII and it eats his drive and burns his TV set, it is only _my_ fault'.
Quoted 4 lines
Patch follows, comments are welcome. Next step is to begin to order the logic, but I wanted to ask first about this.
First cut seems like a good start...
Comments:
* use standard CML indentation
* use CONFIG_X86_ as the prefix for all config symbols you're creating
* Alan's comment seems fair, and also gives me a tangential idea: I wonder if making the CPU features selectable is useful? i.e. provide an actual config option for MMX memcpy, F00F bug, WP, etc. Normal (current) logic is to look at the cpu selected, and deduce these options.
Jeff
Quoted 3 lines · Jeff Garzik
wonder if making the CPU features selectable is useful? i.e. provide an actual config option for MMX memcpy, F00F bug, WP, etc. Normal (current) logic is to look at the cpu selected, and deduce these options.
J.A's comment that most people compiling kernels shouldn't need to know what bugs their CPU has before they pick it is a good one imo[1]
Also an explosion of CONFIG_ items where they can be sanely derived from others doesn't make much sense imo.
Dave.
[1] fsck, I sound like Eric.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 6 lines · On 2002.05.31 Dave Jones wrote:
Quoted 3 lines · Jeff Garzik
wonder if making the CPU features selectable is useful? i.e. provide an actual config option for MMX memcpy, F00F bug, WP, etc. Normal (current) logic is to look at the cpu selected, and deduce these options.
Quoted 6 lines
J.A's comment that most people compiling kernels shouldn't need to know what bugs their CPU has before they pick it is a good one imo[1]
Also an explosion of
CONFIG_items where they can be sanely derived from others doesn't make much sense imo.
As I see it, kernel will only see a CONFIG_CPU_[3456]86 and a bunch of CONFIG_X86-{foof,ppro-fence,mmx, etc}. The others will only be used in CPUConfig.in to derive the visible ones.
Signature · 4 lines
J.A. Magallon # Let the source be with you... mailto:[email protected] Mandrake Linux release 8.3 (Cooker) for i586 Linux werewolf 2.4.19-pre9-jam1 #1 SMP jue may 30 00:48:49 CEST 2002 i686