Skip to contentSkip to conversation

intel-x86 model config cleanup

PATCH In review J.A. Magallon 4 participants 12 messages May 29, 2002 – May 30, 2002 Documentation

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 intel-x86 model config cleanup

Hi all..

One other try.

This is an attempt to clean up the CPU model flags. Changes:

- change names for CONFIG_Mxxxx, trying to make them more intuitive
- split PII from PPro
- introduce X86_F00F config flag and fixmap fix.
- kill CONFIG_M586 as independent flag, and make it just an extra flag for 586 (I couldnt get a better name for MGEN586, suggestions wellcome...)
- kill CONFIG_M686 as independent flag, and make it just an extra flag for anything >= PPro.
- change option order definition to avoid duplicates, like:

if [ "$CONFIG_MPENTIUM" = "y" ]; then
define_bool CONFIG_M586 y <==============
define_bool CONFIG_X86_TSC y
fi
if [ "$CONFIG_MPENTIUMMMX" = "y" ]; then
define_bool CONFIG_M586 y <==============
define_bool CONFIG_X86_TSC y
define_bool CONFIG_X86_GOOD_APIC y
fi
if [ "$CONFIG_M586" = "y" ]; then <======== common things here
define_int CONFIG_X86_L1_CACHE_SHIFT 5 define_bool CONFIG_X86_USE_STRING_486 y define_bool CONFIG_X86_ALIGNMENT_16 y
define_bool CONFIG_X86_PPRO_FENCE y
define_bool CONFIG_X86_F00F_BUG y
fi

Patch follows:

Documentation/Configure.help +6 -5
diff -ruN linux-2.4.19-pre9-jam1/Documentation/Configure.help linux-2.4.19-pre9-jam1-arch/Documentation/Configure.help
@@ -3943,16 +3943,17 @@
   a PPro, but not necessarily on a i486.
 
   Here are the settings recommended for greatest speed:
-   - "386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI
+   - "Generic-386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI
      486DLC/DLC2, UMC 486SX-S and NexGen Nx586.  Only "386" kernels
      will run on a 386 class machine.
-   - "486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or
+   - "Generic-486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or
      SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S.
-   - "586" for generic Pentium CPUs, possibly lacking the TSC
+   - "Generic-586" for generic Pentium CPUs, possibly lacking the TSC
      (time stamp counter) register.
-   - "Pentium-Classic" for the Intel Pentium.
+   - "Pentium" for the Intel Pentium.
    - "Pentium-MMX" for the Intel Pentium MMX.
-   - "Pentium-Pro" for the Intel Pentium Pro/Celeron/Pentium II.
+   - "Pentium-Pro" for the Intel Pentium Pro.
+   - "Pentium-II" for the Intel Pentium II / Celeron.
    - "Pentium-III" for the Intel Pentium III
      and Celerons based on the Coppermine core.
    - "Pentium-4" for the Intel Pentium 4.
arch/i386/Makefile +9 -5
diff -ruN linux-2.4.19-pre9-jam1/arch/i386/Makefile linux-2.4.19-pre9-jam1-arch/arch/i386/Makefile
@@ -34,23 +34,27 @@
 CFLAGS += -march=i486
 endif
 
-ifdef CONFIG_M586
+ifdef CONFIG_MGEN586
 CFLAGS += -march=i586
 endif
 
-ifdef CONFIG_M586TSC
+ifdef CONFIG_MPENTIUM
 CFLAGS += -march=i586
 endif
 
-ifdef CONFIG_M586MMX
+ifdef CONFIG_MPENTIUMMMX
 CFLAGS += -march=i586
 endif
 
-ifdef CONFIG_M686
+ifdef CONFIG_MPENTIUMPRO
 CFLAGS += -march=i686
 endif
 
-ifdef CONFIG_MPENTIUMIII
+ifdef CONFIG_MPENTIUM2
+CFLAGS += -march=i686
+endif
+
+ifdef CONFIG_MPENTIUM3
 CFLAGS += -march=i686
 endif
 
arch/i386/config.in +45 -39

128 lines not on this page · raw message

arch/i386/defconfig +6 -5
diff -ruN linux-2.4.19-pre9-jam1/arch/i386/defconfig linux-2.4.19-pre9-jam1-arch/arch/i386/defconfig
@@ -23,11 +23,12 @@
 #
 # CONFIG_M386 is not set
 # CONFIG_M486 is not set
-# CONFIG_M586 is not set
-# CONFIG_M586TSC is not set
-# CONFIG_M586MMX is not set
-# CONFIG_M686 is not set
-CONFIG_MPENTIUMIII=y
+# CONFIG_MGEN586 is not set
+# CONFIG_MPENTIUM is not set
+# CONFIG_MPENTIUMMMX is not set
+# CONFIG_MPENTIUMPRO is not set
+# CONFIG_MPENTIUM2 is not set
+CONFIG_MPENTIUM3=y
 # CONFIG_MPENTIUM4 is not set
 # CONFIG_MK6 is not set
 # CONFIG_MK7 is not set
arch/i386/kernel/setup.c +3 -4
diff -ruN linux-2.4.19-pre9-jam1/arch/i386/kernel/setup.c linux-2.4.19-pre9-jam1-arch/arch/i386/kernel/setup.c
@@ -2114,13 +2114,10 @@
 
 static void __init init_intel(struct cpuinfo_x86 *c)
 {
-#ifndef CONFIG_M686
-	static int f00f_workaround_enabled = 0;
-#endif
 	char *p = NULL;
 	unsigned int l1i = 0, l1d = 0, l2 = 0, l3 = 0; /* Cache sizes */
 
-#ifndef CONFIG_M686
+#ifdef CONFIG_X86_F00F_BUG
 	/*
 	 * All current models of Pentium and Pentium with MMX technology CPUs
 	 * have the F0 0F bug, which lets nonpriviledged users lock up the system.
@@ -2128,6 +2125,8 @@
 	 */
 	c->f00f_bug = 0;
 	if ( c->x86 == 5 ) {
+		static int f00f_workaround_enabled = 0;
+
 		c->f00f_bug = 1;
 		if ( !f00f_workaround_enabled ) {
 			trap_init_f00f_bug();
arch/i386/kernel/traps.c +3 -21
diff -ruN linux-2.4.19-pre9-jam1/arch/i386/kernel/traps.c linux-2.4.19-pre9-jam1-arch/arch/i386/kernel/traps.c
@@ -757,35 +757,17 @@
 
 #endif /* CONFIG_MATH_EMULATION */
 
-#ifndef CONFIG_M686
+#ifdef CONFIG_X86_F00F_BUG
 void __init trap_init_f00f_bug(void)
 {
-	unsigned long page;
-	pgd_t * pgd;
-	pmd_t * pmd;
-	pte_t * pte;
-
-	/*
-	 * Allocate a new page in virtual address space, 
-	 * move the IDT into it and write protect this page.
-	 */
-	page = (unsigned long) vmalloc(PAGE_SIZE);
-	pgd = pgd_offset(&init_mm, page);
-	pmd = pmd_offset(pgd, page);
-	pte = pte_offset(pmd, page);
-	__free_page(pte_page(*pte));
-	*pte = mk_pte_phys(__pa(&idt_table), PAGE_KERNEL_RO);
-	/*
-	 * Not that any PGE-capable kernel should have the f00f bug ...
-	 */
-	__flush_tlb_all();
+	__set_fixmap(FIX_F00F_IDT, __pa(&idt_table), PAGE_KERNEL_RO);
 
 	/*
 	 * "idt" is magic - it overlaps the idt_descr
 	 * variable so that updating idt will automatically
 	 * update the idt descriptor..
 	 */
-	idt = (struct desc_struct *)page;
+	idt = (struct desc_struct *) fix_to_virt(FIX_F00F_IDT);
 	__asm__ __volatile__("lidt %0": "=m" (idt_descr));
 }
 #endif
arch/i386/mm/fault.c +2 -0
diff -ruN linux-2.4.19-pre9-jam1/arch/i386/mm/fault.c linux-2.4.19-pre9-jam1-arch/arch/i386/mm/fault.c
@@ -281,6 +281,7 @@
 		return;
 	}
 
+#ifdef CONFIG_X86_F00F_BUG
 	/*
 	 * Pentium F0 0F C7 C8 bug workaround.
 	 */
@@ -294,6 +295,7 @@
 			return;
 		}
 	}
+#endif
 
 no_context:
 	/* Are we prepared to handle this kernel fault?  */
include/asm-i386/fixmap.h +3 -0
diff -ruN linux-2.4.19-pre9-jam1/include/asm-i386/fixmap.h linux-2.4.19-pre9-jam1-arch/include/asm-i386/fixmap.h
@@ -61,6 +61,9 @@
 	FIX_LI_PCIA,	/* Lithium PCI Bridge A */
 	FIX_LI_PCIB,	/* Lithium PCI Bridge B */
 #endif
+#ifdef CONFIG_X86_F00F_BUG
+	FIX_F00F_IDT,	/* Virtual mapping for IDT */
+#endif
 #ifdef CONFIG_HIGHMEM
 	FIX_KMAP_BEGIN,	/* reserved pte's for temporary kernel mappings */
 	FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
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 mié may 29 02:20:48 CEST 2002 i686
#1 lore raw
Quoted 53 lines · J.A. Magallon

Hi all..

One other try.

This is an attempt to clean up the CPU model flags. Changes:

- change names for CONFIG_Mxxxx, trying to make them more intuitive
- split PII from PPro
- introduce X86_F00F config flag and fixmap fix.
- kill CONFIG_M586 as independent flag, and make it just an extra flag for 586 (I couldnt get a better name for MGEN586, suggestions wellcome...)
- kill CONFIG_M686 as independent flag, and make it just an extra flag for anything >= PPro.
- change option order definition to avoid duplicates, like:

if [ "$CONFIG_MPENTIUM" = "y" ]; then
define_bool CONFIG_M586 y <==============
define_bool CONFIG_X86_TSC y
fi
if [ "$CONFIG_MPENTIUMMMX" = "y" ]; then
define_bool CONFIG_M586 y <==============
define_bool CONFIG_X86_TSC y
define_bool CONFIG_X86_GOOD_APIC y
fi
if [ "$CONFIG_M586" = "y" ]; then <======== common things here
define_int CONFIG_X86_L1_CACHE_SHIFT 5 define_bool CONFIG_X86_USE_STRING_486 y define_bool CONFIG_X86_ALIGNMENT_16 y
define_bool CONFIG_X86_PPRO_FENCE y
define_bool CONFIG_X86_F00F_BUG y
fi

Patch follows:

diff -ruN linux-2.4.19-pre9-jam1/Documentation/Configure.help linux-2.4.19-pre9-jam1-arch/Documentation/Configure.help

Documentation/Configure.help +3 -3
@@ -3943,16 +3943,17 @@
  a PPro, but not necessarily on a i486.
 
  Here are the settings recommended for greatest speed:
-   - "386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI
+   - "Generic-386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI
     486DLC/DLC2, UMC 486SX-S and NexGen Nx586.  Only "386" kernels
     will run on a 386 class machine.
-   - "486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or
+   - "Generic-486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or
     SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S.
-   - "586" for generic Pentium CPUs, possibly lacking the TSC
+   - "Generic-586" for generic Pentium CPUs, possibly lacking the TSC

Documentation/Configure.help line 3959

Quoted 10 lines
Documentation/Configure.help +3 -2
     (time stamp counter) register.
-   - "Pentium-Classic" for the Intel Pentium.
+   - "Pentium" for the Intel Pentium.
   - "Pentium-MMX" for the Intel Pentium MMX.
-   - "Pentium-Pro" for the Intel Pentium Pro/Celeron/Pentium II.
+   - "Pentium-Pro" for the Intel Pentium Pro.
+   - "Pentium-II" for the Intel Pentium II / Celeron.
   - "Pentium-III" for the Intel Pentium III
     and Celerons based on the Coppermine core.
   - "Pentium-4" for the Intel Pentium 4.

Since you are playing in this area, I wonder if you would consider doing something that has been needed for a while:
Individual CPU selection.

This implies separating the concept of a "generic x86 kernel that supports N CPU types" from "kernel supports one CPU type and one only." The i386/config.in is currently a mishmash of both. Dave Jones did some work along these lines in his "cpuchoice" diff, which I have attached.

Basically, the general direction IMO should be: a user can select the CPU they own (Pentium-II), and none of the options for Pentium 3/4/Athlon will be enabled. Generic kernels would ask for a minimal CPU level to support, I imagine. Support >=486, >=586, etc. Pretty much what we have now.

Jeff

#2 lore raw
In reply to J.A. Magallon
Quoted 2 lines · Jeff Garzik

This implies separating the concept of a "generic x86 kernel that supports N CPU types" from "kernel supports one CPU type and one only." The i386/config.in is currently a mishmash of both. Dave Jones did some work along these lines in his "cpuchoice" diff, which I have attached.

....or rather, attached here.

arch/i386/config.in +63 -10
diff -urN --exclude-from=/home/davej/.exclude linux/arch/i386/config.in linux-dj/arch/i386/config.in
@@ -26,22 +26,75 @@
 
 mainmenu_option next_comment
 comment 'Processor type and features'
-choice 'Processor family' \
+choice 'Processor vendor' \
+	"AMD			CONFIG_VENDOR_AMD \
+	 Cyrix			CONFIG_VENDOR_CYRIX \
+	 Generic		CONFIG_VENDOR_GENERIC \
+	 IDT			CONFIG_VENDOR_IDT \
+	 Intel			CONFIG_VENDOR_INTEL \
+	 NationalSemiconductor	CONFIG_VENDOR_NATSEMI \
+	 RiSE			CONFIG_VENDOR_RISE \
+	 Transmeta		CONFIG_VENDOR_TRANSMETA \
+	 VIA			CONFIG_VENDOR_VIA"	Generic
+
+if [ "$CONFIG_VENDOR_AMD" = "y" ]; then
+	choice 'Processor family' \
+	"386				CONFIG_M386 \
+	 486				CONFIG_M486 \
+	 K5/5x86			CONFIG_M586 \
+	 K6/K6-II/K6-III		CONFIG_MK6 \
+	 Athlon/Duron		CONFIG_MK7" Athlon
+fi
+
+if [ "$CONFIG_VENDOR_CYRIX" = "y" ]; then
+	choice 'Processor family' \
+	"386				CONFIG_M386 \
+	 486				CONFIG_M486 \
+	 586/5x86/6x86/6x86MX		CONFIG_M586" 586
+fi
+
+if [ "$CONFIG_VENDOR_GENERIC" = "y" ]; then
+	choice 'Minimum spec CPU to generate code for' \
+	"386			CONFIG_M386 \
+	 486			CONFIG_M486 \
+	 586			CONFIG_M586 \
+	 686			CONFIG_M686" 386
+fi
+
+if [ "$CONFIG_VENDOR_IDT" = "y" ]; then
+	choice 'Processor family' \
+	"Winchip-C6			CONFIG_MWINCHIPC6 \
+	 Winchip-2			CONFIG_MWINCHIP2 \
+	 Winchip-2A/Winchip-3		CONFIG_MWINCHIP3D" Winchip-C6
+fi
+
+if [ "$CONFIG_VENDOR_INTEL" = "y" ]; then
+	choice 'Processor family' \
 	"386					CONFIG_M386 \
 	 486					CONFIG_M486 \
-	 586/K5/5x86/6x86/6x86MX		CONFIG_M586 \
 	 Pentium-Classic			CONFIG_M586TSC \
 	 Pentium-MMX				CONFIG_M586MMX \
 	 Pentium-Pro/Celeron/Pentium-II		CONFIG_M686 \
 	 Pentium-III/Celeron(Coppermine)	CONFIG_MPENTIUMIII \
-	 Pentium-4				CONFIG_MPENTIUM4 \
-	 K6/K6-II/K6-III			CONFIG_MK6 \
-	 Athlon/Duron/K7			CONFIG_MK7 \
-	 Crusoe					CONFIG_MCRUSOE \
-	 Winchip-C6				CONFIG_MWINCHIPC6 \
-	 Winchip-2				CONFIG_MWINCHIP2 \
-	 Winchip-2A/Winchip-3			CONFIG_MWINCHIP3D \
-	 CyrixIII/C3				CONFIG_MCYRIXIII" Pentium-Pro
+	 Pentium-4				CONFIG_MPENTIUM4" Pentium-Pro
+fi
+
+if [ "$CONFIG_VENDOR_NATSEMI" = "y" ]; then
+	define_bool CONFIG_M586 y
+fi
+
+if [ "$CONFIG_VENDOR_RISE" = "y" ]; then
+	define_bool CONFIG_M586 y
+fi
+
+if [ "$CONFIG_VENDOR_TRANSMETA" = "y" ]; then
+	define_bool CONFIG_MCRUSOE y
+fi
+
+if [ "$CONFIG_VENDOR_VIA" = "y" ]; then
+	define_bool CONFIG_MCYRIXIII y
+fi
+
 #
 # Define implied options from the CPU selection here
 #
#3 lore raw
Quoted 9 lines · Jeff Garzik
arch/i386/config.in +9 -0
+choice 'Processor vendor' \
+	"AMD			CONFIG_VENDOR_AMD \
+	 Cyrix			CONFIG_VENDOR_CYRIX \
+	 Generic		CONFIG_VENDOR_GENERIC \
+	 IDT			CONFIG_VENDOR_IDT \
+	 Intel			CONFIG_VENDOR_INTEL \
+	 NationalSemiconductor	CONFIG_VENDOR_NATSEMI \
+	 RiSE			CONFIG_VENDOR_RISE \
+	 Transmeta		CONFIG_VENDOR_TRANSMETA \

arch/i386/config.in line 47

Quoted 10 lines
arch/i386/config.in +10 -0
+	 VIA			CONFIG_VENDOR_VIA"	Generic
+
+if [ "$CONFIG_VENDOR_AMD" = "y" ]; then
+	choice 'Processor family' \
+	"386				CONFIG_M386 \
+	 486				CONFIG_M486 \
+	 K5/5x86			CONFIG_M586 \
+	 K6/K6-II/K6-III		CONFIG_MK6 \
+	 Athlon/Duron		CONFIG_MK7" Athlon
+fi

This is still a mess. It's better to have one boolean per processor, and order the processors by the year in which they were most commonly sold.

#4 lore raw
In reply to Jeff Garzik
Quoted 4 lines · Albert D. Cahalan

This is still a mess. It's better to have one boolean per processor, and order the processors by the year in which they were most commonly sold.

The information hiding of irrelevant options was one of the motivations behind that original patch. If I know I have an AMD Athlon, showing me all the Intel CPUs just gets in the way. A zillion options in a scrolly list is no better than what we currently have imo.

Signature · 2 lines
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs
#5 lore raw
Quoted 9 lines · Dave Jones
Quoted 3 lines · Albert D. Cahalan

This is still a mess. It's better to have one boolean per processor, and order the processors by the year in which they were most commonly sold.

The information hiding of irrelevant options was one of the motivations behind that original patch. If I know I have an AMD Athlon, showing me all the Intel CPUs just gets in the way.

No, it's like this:

I want one kernel. I have a Pentium-MMX and a Pentium Pro. I don't need support for a 386, 486, Athlon, or Xeon.

It's also like this:

We have a lab full of Athlon and Pentium III boxes. There's not a Pentium 4 in sight, and no Pentium II either. It's too much work to manage multiple kernels; every box must boot from the same disk image.

#6 lore raw
Quoted 6 lines · Albert D. Cahalan

I want one kernel. I have a Pentium-MMX and a Pentium Pro. I don't need support for a 386, 486, Athlon, or Xeon.

It depends on how much work the patch author wants to do. This is a perfectly reasonable request, but increases the complexity of the overall problem somewhat.

Your current solution, whatever it is, should map directly onto one of the 'generic kernel' selections, hopefully. So, what you are really asking for is an RFE to add on to this RFE currently being discussed :)

Jeff

#7 lore raw
In reply to Dave Jones
Quoted 10 lines · Albert D. Cahalan

No, it's like this:
I want one kernel. I have a Pentium-MMX and a Pentium Pro. I don't need support for a 386, 486, Athlon, or Xeon.

It's also like this:

We have a lab full of Athlon and Pentium III boxes. There's not a Pentium 4 in sight, and no Pentium II either. It's too much work to manage multiple kernels; every box must boot from the same disk image.

Ok, I think I see what you're getting at. Instead of a multi-list giving one result, you'd like to tick every box that kernel is going run on, and have it spit out CONFIG_Mxxx for each of those processors.

It's doable, and it keeps things like vendor kernels possible (they just select all CPUs), it's probably quite a bit of work though.

The trickiest bit is getting the Makefile right to choose
the lowest-chosen-denominator in the list for its gcc options, and that's probably not that hard, just a few extra ifdefs in an already ifdef heavy area. Other than that, dealing with the cases like "this cpu has TSC" "this doesn't" and "this has this bug" "this doesn't have this bug" need to be done too, but thats again, just a few more ifdefs away..

Dave.

Signature · 2 lines
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs
#8 lore raw
In reply to J.A. Magallon
Quoted 9 lines · On 2002.05.29 Jeff Garzik wrote:
Quoted 6 lines · Jeff Garzik

This implies separating the concept of a "generic x86 kernel that supports N CPU types" from "kernel supports one CPU type and one only." The i386/config.in is currently a mishmash of both. Dave Jones did some work along these lines in his "cpuchoice" diff, which I have attached.

Could this be organized this way ?

CONFIG_VENDOR_ CONFIG_CPU_ CONFIG_M

GENERIC	       GENERIC_386        386      
               GENERIC_486        486      
               GENERIC_586        586      
               GENERIC_686        686      
INTEL          INTEL_386          386      
               INTEL_486          486      
               INTEL_PENTIUM      586      
               INTEL_PENTIUMMMX   586      
               INTEL_PENTIUMPRO   686      
               INTEL_PENTIUM2     686      
               INTEL_CELERON2     686      
               INTEL_PENTIUM3     686      
               INTEL_CELERON3     686      
               INTEL_PENTIUM4     686      
AMD            AMD_386            386
               AMD_486            486
               AMD_K5             586      
               AMD_K6             K6      
               AMD_K6II           K6      
               AMD_K6III          K6      
               AMD_K7             K7      
               AMD_DURON          K7      
               AMD_ATHLON         K7      
CYRIX          CYRIX_386          386      
               CYRIX_486          486      
               CYRIX_586          586      
               CYRIX_686          686      
VIA            CYRIX_III          686      
TRANSMETA      TRANSMETA_CRUSOE   ???      
NATSEMI        NATSEMI_586        586      
RISE           RISE_586           586      
IDT            IDT_WINCHIPC6      ???      
               IDT_WINCHIP2       ???      
               IDT_WINCHIP2A      ???      
               IDT_WINCHIP3       ???      

Then for each model you would define its generic CONFIG_M<arch>, and the specific features not contained in the generic. And then define the rest of features based on generic.
The CONFIG_M<arch> would serve as a flag for 'this cpu has all features of a generic xxx'.

Or if you are worried about namespace pollution these could be named CONFIG_CPU_VENDOR_, CONFIG_CPU_, CONFIG_CPU_M.

BTW: any more stars in processor vendor/model sky ?

Comments awaited...

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 mié may 29 02:20:48 CEST 2002 i686
#9 lore raw
In reply to J.A. Magallon
Quoted 12 lines · J.A. Magallon

Then for each model you would define its generic CONFIG_M<arch>, and the specific features not contained in the generic. And then define the rest of features based on generic.
The CONFIG_M<arch> would serve as a flag for 'this cpu has all features of a generic xxx'.

Or if you are worried about namespace pollution these could be named CONFIG_CPU_VENDOR_, CONFIG_CPU_, CONFIG_CPU_M.

Your division of categories (snipped from above quoted) seems ok.

The basic thing to remember is that "generic_foo" or "cpu_intel_foo" options should very rarely, if ever, appear in the config.in or sources. We simply want to use the generic or cpu-specific user selection to determine (a) compiler flags, (b) CONFIG_xxx symbols for specific CPU features and optimizations, [like CONFIG_X86_F00F_BUG] and maybe (c) enable and disable CPU-specific drivers. (c) will be a special case, since very few drivers should require a specific CPU type... but some drivers simply don't work on 386.

Jeff

#10 lore raw
In reply to J.A. Magallon
Quoted 10 lines · On 2002.05.30 Jeff Garzik wrote:

The basic thing to remember is that "generic_foo" or "cpu_intel_foo" options should very rarely, if ever, appear in the config.in or sources. We simply want to use the generic or cpu-specific user selection to determine (a) compiler flags, (b) CONFIG_xxx symbols for specific CPU features and optimizations, [like CONFIG_X86_F00F_BUG] and maybe (c) enable and disable CPU-specific drivers. (c) will be a special case, since very few drivers should require a specific CPU type... but some drivers simply don't work on 386.

Grep on the tree showed this:

drivers/char/serial.c:

#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486)) #define SERIAL_INLINE
#endif

include/asm-i386/processor.h:

/* Prefetch instructions for Pentium III and AMD Athlon */ #ifdef CONFIG_MPENTIUMIII

#define ARCH_HAS_PREFETCH
extern inline void prefetch(const void *x)

{
    __asm__ __volatile__ ("prefetchnta (%0)" : : "r"(x));
}

#elif CONFIG_X86_USE_3DNOW

#define ARCH_HAS_PREFETCH
#define ARCH_HAS_PREFETCHW
#define ARCH_HAS_SPINLOCK_PREFETCH

More candidates for CONFIG_X86_xxxxx.
But these spawn over other architextures:
include/asm-alpha/processor.h:#define ARCH_HAS_PREFETCH include/asm-ppc/processor.h:#define ARCH_HAS_PREFETCH
...

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 mié may 29 02:20:48 CEST 2002 i686
#11 lore raw
In reply to J.A. Magallon
Quoted 16 lines · J.A. Magallon
Quoted 4 lines · On 2002.05.30 Jeff Garzik wrote:

The basic thing to remember is that "generic_foo" or "cpu_intel_foo" options should very rarely, if ever, appear in the config.in or sources. We simply want to use the generic or cpu-specific user selection to determine (a) compiler flags, (b) CONFIG_xxx symbols for specific CPU features and optimizations, [like CONFIG_X86_F00F_BUG] and maybe (c) enable and disable CPU-specific drivers. (c) will be a special case, since very few drivers should require a specific CPU type... but some drivers simply don't work on 386.

Grep on the tree showed this:

drivers/char/serial.c:

#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486)) #define SERIAL_INLINE
#endif

Quoted 8 lines

include/asm-i386/processor.h:

/* Prefetch instructions for Pentium III and AMD Athlon */ #ifdef CONFIG_MPENTIUMIII

#define ARCH_HAS_PREFETCH

ARCH_HAS_foo are feature symbols, just like CONFIG_X86_F00F_BUG, so those are fine. They're just cross-architecture, but perform the same task: feature dis/enabling. For the serial example, you'd just need to make sure the net effect of the code is the same, both before and after an x86 config.in cleanup.

Jeff