intel-x86 model config cleanup
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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
- introduceX86_F00Fconfig flag and fixmap fix.
- killCONFIG_M586as independent flag, and make it just an extra flag for 586 (I couldnt get a better name for MGEN586, suggestions wellcome...)
- killCONFIG_M686as 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_boolCONFIG_M586y <==============
define_boolCONFIG_X86_TSCy
fi
if [ "$CONFIG_MPENTIUMMMX" = "y" ]; then
define_boolCONFIG_M586y <==============
define_boolCONFIG_X86_TSCy
define_boolCONFIG_X86_GOOD_APICy
fi
if [ "$CONFIG_M586" = "y" ]; then <======== common things here
define_intCONFIG_X86_L1_CACHE_SHIFT5define_boolCONFIG_X86_USE_STRING_486ydefine_boolCONFIG_X86_ALIGNMENT_16y
define_boolCONFIG_X86_PPRO_FENCEy
define_boolCONFIG_X86_F00F_BUGy
fiPatch 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
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
@@ -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 #
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.
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
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.
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
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
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
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
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_xxxsymbols for specific CPU features and optimizations, [likeCONFIG_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
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_xxxsymbols for specific CPU features and optimizations, [likeCONFIG_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)) #defineSERIAL_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