[PATCH] x86 cpu selection (first hack)

[PATCH] x86 cpu selection (first hack)

[J.A. Magallon]

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.

diff -ruN linux-2.4.19-pre9/arch/i386/config.in linux-2.4.19-pre9-cpu/arch/i386/config.in
--- linux-2.4.19-pre9/arch/i386/config.in	2002-05-29 01:18:23.000000000 +0200
+++ linux-2.4.19-pre9-cpu/arch/i386/config.in	2002-05-30 23:38:06.000000000 +0200
@@ -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
 
diff -ruN linux-2.4.19-pre9/arch/i386/CPUConfig.in linux-2.4.19-pre9-cpu/arch/i386/CPUConfig.in
--- linux-2.4.19-pre9/arch/i386/CPUConfig.in	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.4.19-pre9-cpu/arch/i386/CPUConfig.in	2002-05-31 00:28:31.000000000 +0200
@@ -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


-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
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

Re: [PATCH] x86 cpu selection (first hack)

[J.A. Magallon]

On 2002.05.31 Alan Cox wrote:
>On Thu, 2002-05-30 at 23:50, J.A. Magallon wrote:
>> - 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 ?
>

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.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
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

Re: [PATCH] x86 cpu selection (first hack)

[Jeff Garzik]

J.A. Magallon wrote:

>- 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.
>  
>


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

Re: [PATCH] x86 cpu selection (first hack)

[Dave Jones]

On Thu, May 30, 2002 at 07:20:13PM -0400, Jeff Garzik wrote:

 > 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.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] x86 cpu selection (first hack)

[Alan Cox]

On Thu, 2002-05-30 at 23:50, J.A. Magallon wrote:
> - 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 ?

RE: [PATCH] x86 cpu selection (first hack)

[Leif Sawyer]

Dave Jones replied to 
>Jeff Garzik who wrote:
> 
>> [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.
> 
> 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
> 

Perhaps a comprimise could be made?

Envision a config option where you would have 'expert' choices
for MMX, FOOF, WP, etc.

bool CONFIG_ENABLE_EXPERT_CPU_CHOICES

Leaving this alone would hide the individual tweaks under the
guise of 'least-common-denominator' choices previously suggested.

Re: [PATCH] x86 cpu selection (first hack)

[Jeff Garzik]

Leif Sawyer wrote:

>Dave Jones replied to 
>  
>
>>Jeff Garzik who wrote:
>>
>>    
>>
>>>[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.
>>>      
>>>
>>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
>>
>>    
>>
>
>Perhaps a comprimise could be made?
>
>Envision a config option where you would have 'expert' choices
>for MMX, FOOF, WP, etc.
>  
>


Well...  let's rein in the horses.  Before we go too far down this road, 
I would rather that we just get one thing, individual cpu selection, 
correct.  After that, we can look at making processor features 
selectable, or grouping cpus based on "expert" details like lack of WP 
or supporting TSC.

    Jeff

Re: [PATCH] x86 cpu selection (first hack)

[J.A. Magallon]

On 2002.05.31 Dave Jones wrote:
>On Thu, May 30, 2002 at 07:20:13PM -0400, Jeff Garzik wrote:
>
> > 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.
>

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.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
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