The most important changes since the first version of this patch:
- arch/i386/Makefile updates
- X86_GOOD_APIC -> X86_BAD_APIC
- made arch/i386/kernel/cpu{,mtrr/}/Makefile CPU specific
A 2.6.0-test5 kernel with this patch applied compiled and bootet on
my K6.
This patch makes the bzImage for my computer (same .config, same
compiler, same compiler options) a good 5 kB smaller.
I'd appreciate it if more people could try this patch and report whether
their kernel compiles and works.
The patch below tries to implement a better i386 CPU selection.
In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs
on a 486 and above.
In 2.6 selecting M486 means that only the 486 is supported.
The help text for the X86_GENERIC option says it generates a generic
kernel but the implementation is that it supports CPUs of the selected
M* option and above.
There are two different needs:
1. the installation kernel of a distribution should support all CPUs
this distribution supports (perhaps starting with the 386)
2. a sysadmin might e.g. want a kernel that support both a Pentium-III
and a Pentium 4, but doesn't need to support a 386
The implementation in 2.4 was near to satisfy need 2., if X86_GENERIC in
2.6 was implemented as the help text says it would satisfy the need
of 1.
The patch below against 2.6.0-test5 does a different implementation that
lets you select all CPUs you want to support and it should therefore
suit both needs.
Changes:
- changed the i386 CPU selection from a choice to single options for
every cpu
- renamed the M* variables to CPU_*, this is needed to ask the users
upgrading from older kernels instead of silently changing the
semantics
- made arch/i386/kernel/cpu/Makefile CPU specific
- made arch/i386/kernel/cpu/mtrr/Makefile CPU specific
- X86_GOOD_APIC -> X86_BAD_APIC
- AMD Elan is a different subarch, you can't configure a kernel that
runs on both the AMD Elan and other i386 CPUs
- added optimizing CFLAGS for the AMD Elan
- gcc 2.95 supports -march=k6 (no need for check_gcc)
- even gcc 3.3 doesn't seem to support -march=c3-2, use -march=c3
- help text changes/updates
Questions/TODO:
- please check whether my changes to arch/i386/kernel/cpu{,mtrr/}/Makefile
are correct
- which CPUs exactly need X86_ALIGNMENT_16?
- change include/asm-i386/module.h to use some kind of bitmask
diffstat output:
arch/i386/Kconfig | 255 ++++++++++++-----------------
arch/i386/Makefile | 104 +++++++++--
arch/i386/boot/setup.S | 2
arch/i386/kernel/cpu/Makefile | 34 ++-
arch/i386/kernel/cpu/common.c | 27 +++
arch/i386/kernel/cpu/mtrr/Makefile | 14 +
arch/i386/kernel/cpu/mtrr/main.c | 14 +
arch/i386/lib/mmx.c | 2
arch/i386/mm/init.c | 6
drivers/serial/8250.h | 2
include/asm-i386/apic.h | 4
include/asm-i386/bugs.h | 7
include/asm-i386/module.h | 2
include/asm-i386/processor.h | 4
include/asm-i386/timex.h | 2
15 files changed, 292 insertions(+), 187 deletions(-)
cu
Adrian
--- linux-2.6.0-test5-cpu/arch/i386/Kconfig.old 2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/Kconfig 2003-09-13 14:25:12.000000000 +0200
@@ -43,6 +43,15 @@
help
Choose this option if your computer is a standard PC or compatible.
+config X86_ELAN
+ bool "Elan"
+ help
+ Select this for an AMD Elan processor.
+
+ Do not use this option for K6/Athlon/Opteron processors!
+
+ If unsure choose "PC-compatible" instead.
+
config X86_VOYAGER
bool "Voyager (NCR)"
help
@@ -125,48 +134,19 @@
default y
depends on SMP && X86_ES7000 && MPENTIUMIII
-choice
- prompt "Processor family"
- default M686
-config M386
- bool "386"
- ---help---
- This is the processor type of your CPU. This information is used for
- optimizing purposes. In order to compile a kernel that can run on
- all x86 CPU types (albeit not optimally fast), you can specify
- "386" here.
-
- The kernel will not necessarily run on earlier architectures than
- the one you have chosen, e.g. a Pentium optimized kernel will run on
- 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
- 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
- SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S.
- - "586" for generic Pentium CPUs lacking the TSC
- (time stamp counter) register.
- - "Pentium-Classic" for the Intel Pentium.
- - "Pentium-MMX" for the Intel Pentium MMX.
- - "Pentium-Pro" for the Intel Pentium Pro.
- - "Pentium-II" for the Intel Pentium II or pre-Coppermine Celeron.
- - "Pentium-III" for the Intel Pentium III or Coppermine Celeron.
- - "Pentium-4" for the Intel Pentium 4 or P4-based Celeron.
- - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
- - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
- - "Crusoe" for the Transmeta Crusoe series.
- - "Winchip-C6" for original IDT Winchip.
- - "Winchip-2" for IDT Winchip 2.
- - "Winchip-2A" for IDT Winchips with 3dNow! capabilities.
- - "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3.
- - "VIA C3-2 for VIA C3-2 "Nehemiah" (model 9 and above).
+if !X86_ELAN
+
+menu "Processor support"
- If you don't know what to do, choose "386".
+comment "Select all processors your kernel should support"
-config M486
+config CPU_386
+ bool "386"
+ help
+ Select this for a 386 series processor.
+
+config CPU_486
bool "486"
help
Select this for a 486 series processor, either Intel or one of the
@@ -174,227 +154,220 @@
DX2, and DX4 variants; also SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or
U5S.
-config M586
+config CPU_586
bool "586/K5/5x86/6x86/6x86MX"
help
- Select this for an 586 or 686 series processor such as the AMD K5,
- the Intel 5x86 or 6x86, or the Intel 6x86MX. This choice does not
- assume the RDTSC (Read Time Stamp Counter) instruction.
+ Select this for a non-Intel 586 or 686 series processor such as
+ the AMD K5 or the Cyrix 6x86MX.
+
+ Several CPUs that have their own options below (e.g. AMD K6,
+ Duron, Athlon and Opteeron, IDT Winchip, Cyrix III and
+ VIA C3) do _not_ need this option.
+
+ This choice does not assume the RDTSC (Read Time Stamp Counter)
+ instruction.
-config M586TSC
+config CPU_586TSC
bool "Pentium-Classic"
help
Select this for a Pentium Classic processor with the RDTSC (Read
- Time Stamp Counter) instruction for benchmarking.
+ Time Stamp Counter) instruction.
-config M586MMX
+config CPU_586MMX
bool "Pentium-MMX"
help
Select this for a Pentium with the MMX graphics/multimedia
extended instructions.
-config M686
+config CPU_686
bool "Pentium-Pro"
help
- Select this for Intel Pentium Pro chips. This enables the use of
- Pentium Pro extended instructions, and disables the init-time guard
- against the f00f bug found in earlier Pentiums.
+ Select this for Intel Pentium Pro chips.
-config MPENTIUMII
+config CPU_PENTIUMII
bool "Pentium-II/Celeron(pre-Coppermine)"
help
Select this for Intel chips based on the Pentium-II and
- pre-Coppermine Celeron core. This option enables an unaligned
- copy optimization, compiles the kernel with optimization flags
- tailored for the chip, and applies any applicable Pentium Pro
- optimizations.
+ pre-Coppermine Celeron core.
-config MPENTIUMIII
+config CPU_PENTIUMIII
bool "Pentium-III/Celeron(Coppermine)/Pentium-III Xeon"
help
Select this for Intel chips based on the Pentium-III and
- Celeron-Coppermine core. This option enables use of some
- extended prefetch instructions in addition to the Pentium II
- extensions.
+ Celeron-Coppermine core.
-config MPENTIUM4
+config CPU_PENTIUM4
bool "Pentium-4/Celeron(P4-based)/Xeon"
help
Select this for Intel Pentium 4 chips. This includes both
- the Pentium 4 and P4-based Celeron chips. This option
- enables compile flags optimized for the chip, uses the
- correct cache shift, and applies any applicable Pentium III
- optimizations.
+ the Pentium 4 and P4-based Celeron chips.
-config MK6
+config CPU_K6
bool "K6/K6-II/K6-III"
help
- Select this for an AMD K6-family processor. Enables use of
- some extended instructions, and passes appropriate optimization
- flags to GCC.
+ Select this for an AMD K6, K6-II or K6-III (aka K6-3D).
-config MK7
+config CPU_K7
bool "Athlon/Duron/K7"
help
- Select this for an AMD Athlon K7-family processor. Enables use of
- some extended instructions, and passes appropriate optimization
- flags to GCC.
+ Select this for an AMD Athlon K7-family processor.
-config MK8
+config CPU_K8
bool "Opteron/Athlon64/Hammer/K8"
help
- Select this for an AMD Opteron or Athlon64 Hammer-family processor. Enables
- use of some extended instructions, and passes appropriate optimization
- flags to GCC.
+ Select this for an AMD Opteron or Athlon64 Hammer-family processor.
-config MELAN
- bool "Elan"
-
-config MCRUSOE
+config CPU_CRUSOE
bool "Crusoe"
help
- Select this for a Transmeta Crusoe processor. Treats the processor
- like a 586 with TSC, and sets some GCC optimization flags (like a
- Pentium Pro with no alignment requirements).
+ Select this for a Transmeta Crusoe processor.
-config MWINCHIPC6
+config CPU_WINCHIPC6
bool "Winchip-C6"
help
- Select this for an IDT Winchip C6 chip. Linux and GCC
- treat this chip as a 586TSC with some extended instructions
- and alignment requirements.
+ Select this for an IDT Winchip C6 chip.
-config MWINCHIP2
+config CPU_WINCHIP2
bool "Winchip-2"
help
- Select this for an IDT Winchip-2. Linux and GCC
- treat this chip as a 586TSC with some extended instructions
- and alignment requirements.
+ Select this for an IDT Winchip-2.
-config MWINCHIP3D
+config CPU_WINCHIP3D
bool "Winchip-2A/Winchip-3"
help
- Select this for an IDT Winchip-2A or 3. Linux and GCC
- treat this chip as a 586TSC with some extended instructions
- and alignment reqirements. Also enable out of order memory
- stores for this CPU, which can increase performance of some
- operations.
-
-config MCYRIXIII
- bool "CyrixIII/VIA-C3"
- help
- Select this for a Cyrix III or C3 chip. Presently Linux and GCC
- treat this chip as a generic 586. Whilst the CPU is 686 class,
- it lacks the cmov extension which gcc assumes is present when
- generating 686 code.
- Note that Nehemiah (Model 9) and above will not boot with this
- kernel due to them lacking the 3DNow! instructions used in earlier
- incarnations of the CPU.
+ Select this for an IDT Winchip-2A or 3 with 3dNow!
+ capabilities.
+
+config CPU_CYRIXIII
+ bool "Cyrix III/VIA C3"
+ help
+ Select this for a Cyrix III or VIA C3 chip.
-config MVIAC3_2
+ Note that Nehemiah (Model 9) and above need the next
+ option instead.
+
+config CPU_VIAC3_2
bool "VIA C3-2 (Nehemiah)"
help
- Select this for a VIA C3 "Nehemiah". Selecting this enables usage
- of SSE and tells gcc to treat the CPU as a 686.
- Note, this kernel will not boot on older (pre model 9) C3s.
+ Select this for a VIA C3 "Nehemiah" (model 9 and above).
-endchoice
+endmenu
-config X86_GENERIC
- bool "Generic x86 support"
- help
- Including some tuning for non selected x86 CPUs too.
- when it has moderate overhead. This is intended for generic
- distributions kernels.
+endif
+
+#
+# helper options
+#
+config CPU_INTEL
+ bool
+ depends on CPU_386 || CPU_486 || CPU_586TSC || CPU_686 || CPU_PENTIUMII || CPU_PENTIUMIII || CPU_PENTIUM4
+
+config CPU_WINCHIP
+ bool
+ depends on CPU_WINCHIPC6 || CPU_WINCHIP2 || CPU_WINCHIP3D
+ default y
+
+config CPU_ONLY_K7
+ bool
+ depends on CPU_K7 && !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+
+config CPU_ONLY_K8
+ bool
+ depends on CPU_K8 && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+
+config CPU_ONLY_WINCHIP
+ bool
+ depends on CPU_WINCHIP && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_CYRIXIII && !CPU_VIAC3_2
+ default y
#
# Define implied options from the CPU selection here
#
config X86_CMPXCHG
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_XADD
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_L1_CACHE_SHIFT
int
- default "7" if MPENTIUM4 || X86_GENERIC
- default "4" if MELAN || M486 || M386
- default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2
- default "6" if MK7 || MK8
+ default "7" if CPU_PENTIUM4
+ default "6" if CPU_K7 || CPU_K8
+ default "5" if CPU_WINCHIP || CPU_CRUSOE || CPU_CYRIXIII || CPU_K6 || CPU_PENTIUMIII || CPU_PENTIUMII || CPU_686 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_VIAC3_2
+ default "4" if X86_ELAN || CPU_486 || CPU_386
config RWSEM_GENERIC_SPINLOCK
bool
- depends on M386
+ depends on CPU_386
default y
config RWSEM_XCHGADD_ALGORITHM
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_PPRO_FENCE
bool
- depends on M686 || M586MMX || M586TSC || M586 || M486 || M386
+ depends on CPU_686
default y
config X86_F00F_BUG
bool
- depends on M586MMX || M586TSC || M586 || M486 || M386
+ depends on CPU_586MMX || CPU_586TSC
default y
config X86_WP_WORKS_OK
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_INVLPG
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_BSWAP
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_POPAD_OK
bool
- depends on !M386
+ depends on !CPU_386
default y
config X86_ALIGNMENT_16
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
+ depends on CPU_WINCHIP || CPU_CYRIXIII || X86_ELAN || CPU_K6 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_486 || CPU_VIAC3_2
default y
-config X86_GOOD_APIC
+config X86_BAD_APIC
bool
- depends on MK7 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8
+ depends on CPU_586TSC
default y
config X86_INTEL_USERCOPY
bool
- depends on MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7
+ depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_686 && !CPU_K6 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
default y
config X86_USE_PPRO_CHECKSUM
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2
+ depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !X86_ELAN && !CPU_CRUSOE
default y
config X86_USE_3DNOW
bool
- depends on MCYRIXIII || MK7
+ depends on !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_VIAC3_2
default y
config X86_OOSTORE
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6
+ depends on CPU_ONLY_WINCHIP
default y
config HUGETLB_PAGE
@@ -517,7 +490,7 @@
config X86_TSC
bool
- depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2) && !X86_NUMAQ
+ depends on !X86_NUMAQ && !CPU_386 && !CPU_486 && !CPU_586 && !X86_ELAN && !CPU_WINCHIPC6
default y
config X86_MCE
--- linux-2.6.0-test5-cpu/arch/i386/Makefile.old 2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/Makefile 2003-09-13 12:51:08.000000000 +0200
@@ -28,28 +28,94 @@
align := $(subst -functions=0,,$(call check_gcc,-falign-functions=0,-malign-functions=0))
-cflags-$(CONFIG_M386) += -march=i386
-cflags-$(CONFIG_M486) += -march=i486
-cflags-$(CONFIG_M586) += -march=i586
-cflags-$(CONFIG_M586TSC) += -march=i586
-cflags-$(CONFIG_M586MMX) += $(call check_gcc,-march=pentium-mmx,-march=i586)
-cflags-$(CONFIG_M686) += -march=i686
-cflags-$(CONFIG_MPENTIUMII) += $(call check_gcc,-march=pentium2,-march=i686)
-cflags-$(CONFIG_MPENTIUMIII) += $(call check_gcc,-march=pentium3,-march=i686)
-cflags-$(CONFIG_MPENTIUM4) += $(call check_gcc,-march=pentium4,-march=i686)
-cflags-$(CONFIG_MK6) += $(call check_gcc,-march=k6,-march=i586)
+ifdef CONFIG_CPU_PENTIUM4
+ cpuflags-y := $(call check_gcc,-march=pentium4,-march=i686)
+endif
+
+ifdef CONFIG_CPU_K8
+ ifdef CONFIG_CPU_PENTIUM4
+ cpuflags-y := $(call check_gcc,-march=pentium3,-march=i686)
+ else
+ cpuflags-y := $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
+ endif
+endif
+
# Please note, that patches that add -march=athlon-xp and friends are pointless.
# They make zero difference whatsosever to performance at this time.
-cflags-$(CONFIG_MK7) += $(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4)
-cflags-$(CONFIG_MK8) += $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
-cflags-$(CONFIG_MCRUSOE) += -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
-cflags-$(CONFIG_MWINCHIPC6) += $(call check_gcc,-march=winchip-c6,-march=i586)
-cflags-$(CONFIG_MWINCHIP2) += $(call check_gcc,-march=winchip2,-march=i586)
-cflags-$(CONFIG_MWINCHIP3D) += $(call check_gcc,-march=winchip2,-march=i586)
-cflags-$(CONFIG_MCYRIXIII) += $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
-cflags-$(CONFIG_MVIAC3_2) += $(call check_gcc,-march=c3-2,-march=i686)
+ifdef CONFIG_CPU_K7
+ ifdef CONFIG_CPU_PENTIUM4
+ cpuflags-y := $(call check_gcc,-march=pentium3,-march=i686)
+ else
+ cpuflags-y := $(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4)
+ endif
+endif
+
+ifdef CONFIG_CPU_PENTIUMIII
+cpuflags-y := $(call check_gcc,-march=pentium3,-march=i686)
+endif
+
+ifdef CONFIG_CPU_PENTIUMII
+cpuflags-y := $(call check_gcc,-march=pentium2,-march=i686)
+endif
+
+ifdef CONFIG_CPU_VIAC3_2
+ cpuflags-y := $(call check_gcc,-march=c3,-march=i686)
+endif
+
+ifdef CONFIG_CPU_CRUSOE
+ cpuflags-y := -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
+endif
+
+ifdef CONFIG_CPU_686
+ cpuflags-y := -march=i686
+endif
+
+# supports i686 without cmov
+ifdef CONFIG_CPU_CYRIXIII
+ cpuflags-y := $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
+endif
+
+ifdef CONFIG_CPU_K6
+ cpuflags-y := -march=k6
+endif
+
+ifdef CONFIG_CPU_586MMX
+ cpuflags-y := $(call check_gcc,-march=pentium-mmx,-march=i586)
+endif
+
+# Winchip supports i586
+ifdef CONFIG_CPU_WINCHIPC6
+ cpuflags-y := $(call check_gcc,-march=winchip-c6,-march=i486)
+endif
+ifdef CONFIG_CPU_WINCHIP2
+ cpuflags-y := $(call check_gcc,-march=winchip2,-march=i486)
+endif
+ifdef CPU_WINCHIP3D
+ cpuflags-y := $(call check_gcc,-march=winchip2,-march=i486)
+endif
+
+ifdef CONFIG_CPU_586TSC
+cpuflags-y := -march=i586
+endif
+
+ifdef CONFIG_CPU_586
+ cpuflags-y := -march=i586
+endif
+
+ifdef CONFIG_X86_ELAN
+ cpuflags-y := -march=i486
+endif
+
+ifdef CONFIG_CPU_486
+ cpuflags-y := -march=i486
+endif
+
+ifdef CONFIG_CPU_386
+ cpuflags-y := -march=i386
+endif
+
-CFLAGS += $(cflags-y)
+CFLAGS += $(cpuflags-y)
# Default subarch .c files
mcore-y := mach-default
--- linux-2.6.0-test5-cpu/include/asm-i386/processor.h.old 2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/include/asm-i386/processor.h 2003-09-13 11:14:10.000000000 +0200
@@ -541,7 +541,7 @@
#define K7_NOP7 ".byte 0x8D,0x04,0x05,0,0,0,0\n"
#define K7_NOP8 K7_NOP7 ASM_NOP1
-#ifdef CONFIG_MK8
+#ifdef CONFIG_CPU_ONLY_K8
#define ASM_NOP1 K8_NOP1
#define ASM_NOP2 K8_NOP2
#define ASM_NOP3 K8_NOP3
@@ -550,7 +550,7 @@
#define ASM_NOP6 K8_NOP6
#define ASM_NOP7 K8_NOP7
#define ASM_NOP8 K8_NOP8
-#elif defined(CONFIG_MK7)
+#elif defined(CONFIG_CPU_ONLY_K7)
#define ASM_NOP1 K7_NOP1
#define ASM_NOP2 K7_NOP2
#define ASM_NOP3 K7_NOP3
--- linux-2.6.0-test5-cpu/drivers/serial/8250.h.old 2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/drivers/serial/8250.h 2003-09-13 11:14:10.000000000 +0200
@@ -44,7 +44,7 @@
#undef SERIAL_DEBUG_PCI
-#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486))
+#if defined(__i386__) && (defined(CONFIG_CPU_386) || defined(CONFIG_CPU_486))
#define SERIAL_INLINE
#endif
--- linux-2.6.0-test5-cpu/arch/i386/boot/setup.S.old 2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/boot/setup.S 2003-09-13 11:14:10.000000000 +0200
@@ -744,7 +744,7 @@
# AMD Elan bug fix by Robert Schwebel.
#
-#if defined(CONFIG_MELAN)
+#if defined(CONFIG_X86_ELAN)
movb $0x02, %al # alternate A20 gate
outb %al, $0x92 # this works on SC410/SC520
a20_elan_wait:
--- linux-2.6.0-test5-cpu/include/asm-i386/timex.h.old 2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/include/asm-i386/timex.h 2003-09-13 11:14:10.000000000 +0200
@@ -12,7 +12,7 @@
#ifdef CONFIG_X86_PC9800
extern int CLOCK_TICK_RATE;
#else
-#ifdef CONFIG_MELAN
+#ifdef CONFIG_X86_ELAN
# define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
#else
# define CLOCK_TICK_RATE 1193182 /* Underlying HZ */
--- linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c.old 2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c 2003-09-13 11:17:00.000000000 +0200
@@ -121,7 +121,7 @@
return p;
}
-#ifdef CONFIG_MK7
+#ifndef CONFIG_CPU_CYRIXIII
/*
* The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
--- linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/Makefile.old 2003-09-13 11:25:13.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/Makefile 2003-09-13 14:21:27.000000000 +0200
@@ -2,16 +2,32 @@
# Makefile for x86-compatible CPU details and quirks
#
-obj-y := common.o proc.o
+obj-y := common.o proc.o
+
+
+obj-$(CONFIG_CPU_486) += amd.o
+obj-$(CONFIG_CPU_586) += amd.o
+obj-$(CONFIG_CPU_K6) += amd.o
+obj-$(CONFIG_CPU_K7) += amd.o
+obj-$(CONFIG_CPU_K8) += amd.o
+
+obj-$(CONFIG_CPU_WINCHIP) += centaur.o
+obj-$(CONFIG_CPU_CYRIXIII) += centaur.o
+obj-$(CONFIG_CPU_VIAC3_2) += centaur.o
+
+obj-$(CONFIG_CPU_486) += cyrix.o
+obj-$(CONFIG_CPU_586) += cyrix.o
+
+obj-$(CONFIG_CPU_INTEL) += intel.o
+
+obj-$(CONFIG_CPU_586) += nexgen.o
+
+obj-$(CONFIG_CPU_586) += rise.o
+
+obj-$(CONFIG_CPU_CRUSOE) += transmeta.o
+
+obj-$(CONFIG_CPU_486) += umc.o
-obj-y += amd.o
-obj-y += cyrix.o
-obj-y += centaur.o
-obj-y += transmeta.o
-obj-y += intel.o
-obj-y += rise.o
-obj-y += nexgen.o
-obj-y += umc.o
obj-$(CONFIG_X86_MCE) += mcheck/
--- linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/common.c.old 2003-09-13 13:58:07.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/common.c 2003-09-13 14:20:59.000000000 +0200
@@ -434,15 +434,42 @@
void __init early_cpu_init(void)
{
+
+#if defined(CONFIG_CPU_INTEL)
intel_cpu_init();
+#endif
+
+#if defined(CONFIG_CPU_486) || defined(CONFIG_CPU_586)
cyrix_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_486)
nsc_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_486) || defined(CONFIG_CPU_586) || defined(CONFIG_CPU_K6) || defined(CONFIG_CPU_K7) || defined(CONFIG_CPU_K8)
amd_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
centaur_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_CRUSOE)
transmeta_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_586)
rise_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_586)
nexgen_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_486)
umc_init_cpu();
+#endif
#ifdef CONFIG_DEBUG_PAGEALLOC
/* pse is not compatible with on-the-fly unmapping,
--- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old 2003-09-13 14:18:04.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c 2003-09-13 14:23:26.000000000 +0200
@@ -436,8 +436,12 @@
if (!mem_map)
BUG();
#endif
-
+
+#ifdef CONFIG_CPU_686
bad_ppro = ppro_with_ram_bug();
+#else
+ bad_ppro = 0;
+#endif
#ifdef CONFIG_HIGHMEM
/* check that fixmap and pkmap do not overlap */
--- linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/mtrr/Makefile.old 2003-09-13 11:25:27.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/mtrr/Makefile 2003-09-13 14:14:20.000000000 +0200
@@ -1,5 +1,11 @@
-obj-y := main.o if.o generic.o state.o
-obj-y += amd.o
-obj-y += cyrix.o
-obj-y += centaur.o
+obj-y := main.o if.o generic.o state.o
+
+obj-$(CONFIG_CPU_K6) += amd.o
+
+obj-$(CONFIG_CPU_586) += cyrix.o
+
+obj-$(CONFIG_CPU_WINCHIP) += centaur.o
+obj-$(CONFIG_CPU_CYRIXIII) += centaur.o
+obj-$(CONFIG_CPU_VIAC3_2) += centaur.o
+
--- linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/mtrr/main.c.old 2003-09-13 14:04:35.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/mtrr/main.c 2003-09-13 14:09:11.000000000 +0200
@@ -475,12 +475,16 @@
printk(KERN_WARNING "mtrr: register: %d too big\n", reg);
goto out;
}
+
+#if defined(CONFIG_CPU_586)
if (is_cpu(CYRIX) && !use_intel()) {
if ((reg == 3) && arr3_protected) {
printk(KERN_WARNING "mtrr: ARR3 cannot be changed\n");
goto out;
}
}
+#endif
+
mtrr_if->get(reg, &lbase, &lsize, <ype);
if (lsize < 1) {
printk(KERN_WARNING "mtrr: MTRR %d not used\n", reg);
@@ -536,9 +540,19 @@
static void __init init_ifs(void)
{
+
+#if defined(CONFIG_CPU_K6)
amd_init_mtrr();
+#endif
+
+#if defined(CONFIG_CPU_586)
cyrix_init_mtrr();
+#endif
+
+#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
centaur_init_mtrr();
+#endif
+
}
static void init_other_cpus(void)
--- linux-2.6.0-test5-cpu/include/asm-i386/bugs.h.old 2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/include/asm-i386/bugs.h 2003-09-13 11:16:23.000000000 +0200
@@ -152,9 +152,8 @@
* - In order to run on anything without a TSC, we need to be
* compiled for a i486.
* - In order to support the local APIC on a buggy Pentium machine,
- * we need to be compiled with CONFIG_X86_GOOD_APIC disabled,
- * which happens implicitly if compiled for a Pentium or lower
- * (unless an advanced selection of CPU features is used) as an
+ * we need to be compiled with CONFIG_X86_BAD_APIC enabled,
+ * which happens implicitly if compiled for a Pentium as an
* otherwise config implies a properly working local APIC without
* the need to do extra reads from the APIC.
*/
@@ -185,7 +184,7 @@
* integrated APIC (see 11AP erratum in "Pentium Processor
* Specification Update").
*/
-#if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_X86_GOOD_APIC)
+#if defined(CONFIG_X86_LOCAL_APIC) && !defined(CONFIG_X86_BAD_APIC)
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
&& cpu_has_apic
&& boot_cpu_data.x86 == 5
--- linux-2.6.0-test5-cpu/include/asm-i386/apic.h.old 2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/include/asm-i386/apic.h 2003-09-13 11:15:42.000000000 +0200
@@ -41,7 +41,7 @@
do { } while ( apic_read( APIC_ICR ) & APIC_ICR_BUSY );
}
-#ifdef CONFIG_X86_GOOD_APIC
+#ifndef CONFIG_X86_BAD_APIC
# define FORCE_READ_AROUND_WRITE 0
# define apic_read_around(x)
# define apic_write_around(x,y) apic_write((x),(y))
@@ -56,7 +56,7 @@
/*
* ack_APIC_irq() actually gets compiled as a single instruction:
* - a single rmw on Pentium/82489DX
- * - a single write on P6+ cores (CONFIG_X86_GOOD_APIC)
+ * - a single write on P6+ cores (!CONFIG_X86_BAD_APIC)
* ... yummie.
*/
--- linux-2.6.0-test5-cpu/include/asm-i386/module.h.old 2003-09-13 12:52:18.000000000 +0200
+++ linux-2.6.0-test5-cpu/include/asm-i386/module.h 2003-09-13 13:03:13.000000000 +0200
@@ -49,7 +49,7 @@
#elif CONFIG_MVIAC3_2
#define MODULE_PROC_FAMILY "VIAC3-2 "
#else
-#error unknown processor family
+#define MODULE_PROC_FAMILY "this needs to be fixed"
#endif
#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY
Adrian Bunk wrote:
> I'd appreciate it if more people could try this patch and report whether
> their kernel compiles and works.
Compiling with config below produces linking errors:
arch/i386/lib/lib.a(usercopy.o): In function `__copy_to_user_ll':
usercopy.o(.text+0x279): undefined reference to `movsl_mask'
arch/i386/lib/lib.a(usercopy.o): In function `__copy_from_user_ll':
usercopy.o(.text+0x2e9): undefined reference to `movsl_mask'
.config:
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_STANDALONE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_X86_PC=y
CONFIG_CPU_K7=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_ACPI_HT=y
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_PCI=y
CONFIG_PCI_GODIRECT=y
CONFIG_PCI_DIRECT=y
CONFIG_HOTPLUG=y
CONFIG_BINFMT_ELF=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_IDE_TASKFILE_IO=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_BLK_DEV_3W_XXXX_RAID=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IPV6_SCTP__=y
CONFIG_NETDEVICES=y
CONFIG_TUN=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_TULIP=y
CONFIG_TULIP=y
CONFIG_TULIP_MMIO=y
CONFIG_NET_PCI=y
CONFIG_NATSEMI=y
CONFIG_SIS900=y
CONFIG_NS83820=y
# Token Ring devices (depends on LLC=y)
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_SOUND_GAMEPORT=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_AGP=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_DRM=y
CONFIG_DRM_R128=y
CONFIG_EXT2_FS=y
CONFIG_XFS_FS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_PROC_FS=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
CONFIG_DEVPTS_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_FB=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_ATY128=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_INTEL8X0=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_PRINTER=y
CONFIG_USB_STORAGE=y
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
CONFIG_USB_USBNET=y
CONFIG_USB_CDCETHER=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_BIOS_REBOOT=y
On Sat, Sep 13, 2003 at 02:51:03PM +0200, Adrian Bunk wrote:
> This patch makes the bzImage for my computer (same .config, same
> compiler, same compiler options) a good 5 kB smaller.
For the invasiveness of the patch, 5KB really is a questionable gain..
> In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs
> on a 486 and above.
> In 2.6 selecting M486 means that only the 486 is supported.
What are you basing this on ? This seems bogus to me.
Last I checked, I could for eg, boot a 386 kernel on an Athlon.
> +config CPU_VIAC3_2
> bool "VIA C3-2 (Nehemiah)"
> help
> - Select this for a VIA C3 "Nehemiah". Selecting this enables usage
> - of SSE and tells gcc to treat the CPU as a 686.
> - Note, this kernel will not boot on older (pre model 9) C3s.
> + Select this for a VIA C3 "Nehemiah" (model 9 and above).
You lost an important part of helptext.
> +config CPU_ONLY_K7
> + bool
> + depends on CPU_K7 && !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
> +
> +config CPU_ONLY_K8
> + bool
> + depends on CPU_K8 && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
> +
> +config CPU_ONLY_WINCHIP
> + bool
> + depends on CPU_WINCHIP && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_CYRIXIII && !CPU_VIAC3_2
> + default y
These are hurrendous. Each time we add support for a new CPU we
have to update each and every one of these. This won't fly,
someone *WILL* miss one. We've had this sort of thing happen before,
and its an accident waiting to happen.
> +
> +ifdef CONFIG_CPU_K8
> + ifdef CONFIG_CPU_PENTIUM4
> + cpuflags-y := $(call check_gcc,-march=pentium3,-march=i686)
> + else
> + cpuflags-y := $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
> + endif
> +endif
> +
These horrible nesting things are also a real PITA, as theres >1 case
that needs updating when something changes for a particular
vendor/family. The cflags-$foo stuff in 2.6 was just starting to
become readable, and you want to undo that?
> --- linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c.old 2003-09-13 11:14:00.000000000 +0200
> +++ linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c 2003-09-13 11:17:00.000000000 +0200
> @@ -121,7 +121,7 @@
> return p;
> }
>
> -#ifdef CONFIG_MK7
> +#ifndef CONFIG_CPU_CYRIXIII
>
> /*
> * The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
wtf ?
> --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old 2003-09-13 14:18:04.000000000 +0200
> +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c 2003-09-13 14:23:26.000000000 +0200
> @@ -436,8 +436,12 @@
> if (!mem_map)
> BUG();
> #endif
> -
> +
> +#ifdef CONFIG_CPU_686
> bad_ppro = ppro_with_ram_bug();
> +#else
> + bad_ppro = 0;
> +#endif
>
If we boot a 386 kernel on a ppro with that bug, this goes bang.
> static void __init init_ifs(void)
> {
> +
> +#if defined(CONFIG_CPU_K6)
> amd_init_mtrr();
> +#endif
> +
> +#if defined(CONFIG_CPU_586)
> cyrix_init_mtrr();
> +#endif
> +
> +#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
> centaur_init_mtrr();
> +#endif
> +
For the handful of bytes saved in the mtrr driver, I'm more concerned
about ifdef noise, and the fact that we don't have a compile once-run
everywhere MTRR driver anymore unless you pick your options right
Dave
--
Dave Jones http://www.codemonkey.org.uk
On Sat, Sep 13, 2003 at 05:11:49PM +0100, Dave Jones wrote:
> On Sat, Sep 13, 2003 at 02:51:03PM +0200, Adrian Bunk wrote:
>
> > This patch makes the bzImage for my computer (same .config, same
> > compiler, same compiler options) a good 5 kB smaller.
>
> For the invasiveness of the patch, 5KB really is a questionable gain..
I should have stated that the arch/i386/kernel/cpu{,/mtrr}/Makefile
parts are an example of what is possible with such a CPU selection
schema.
I'll send a splitted patch where this is only an optional enhanchement.
> > In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs
> > on a 486 and above.
> > In 2.6 selecting M486 means that only the 486 is supported.
>
> What are you basing this on ? This seems bogus to me.
> Last I checked, I could for eg, boot a 386 kernel on an Athlon.
It currently works. The question is the exact semantics of X86_GENERIC.
If you read the description of X86_GENERIC it implicitely says a kernel
for a 386 isn't generic.
> > +config CPU_VIAC3_2
> > bool "VIA C3-2 (Nehemiah)"
> > help
> > - Select this for a VIA C3 "Nehemiah". Selecting this enables usage
> > - of SSE and tells gcc to treat the CPU as a 686.
> > - Note, this kernel will not boot on older (pre model 9) C3s.
> > + Select this for a VIA C3 "Nehemiah" (model 9 and above).
>
> You lost an important part of helptext.
With the patch to the Makefile the "enables usage of SSE and tells gcc
to treat the CPU as a 686" is only true if you don't compile support for
older CPUs.
>...
> > +
> > +ifdef CONFIG_CPU_K8
> > + ifdef CONFIG_CPU_PENTIUM4
> > + cpuflags-y := $(call check_gcc,-march=pentium3,-march=i686)
> > + else
> > + cpuflags-y := $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
> > + endif
> > +endif
> > +
>
> These horrible nesting things are also a real PITA, as theres >1 case
> that needs updating when something changes for a particular
> vendor/family. The cflags-$foo stuff in 2.6 was just starting to
> become readable, and you want to undo that?
The idea is to move the question "Which CPU option supports bot an
Athlon and a Pentium 4?" from the user to the kernel. The user no longer
has to take care of this, he simply selects all CPUs he wants to
support.
> > --- linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c.old 2003-09-13 11:14:00.000000000 +0200
> > +++ linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c 2003-09-13 11:17:00.000000000 +0200
> > @@ -121,7 +121,7 @@
> > return p;
> > }
> >
> > -#ifdef CONFIG_MK7
> > +#ifndef CONFIG_CPU_CYRIXIII
> >
> > /*
> > * The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
>
> wtf ?
It's logical considering the dependencies of X86_USE_3DNOW.
But thinking about it a second time, it seems a CONFIG_CPU_ONLY_K7 does
the same and is less error prone.
> > --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old 2003-09-13 14:18:04.000000000 +0200
> > +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c 2003-09-13 14:23:26.000000000 +0200
> > @@ -436,8 +436,12 @@
> > if (!mem_map)
> > BUG();
> > #endif
> > -
> > +
> > +#ifdef CONFIG_CPU_686
> > bad_ppro = ppro_with_ram_bug();
> > +#else
> > + bad_ppro = 0;
> > +#endif
> >
>
> If we boot a 386 kernel on a ppro with that bug, this goes bang.
ppro_with_ram_bug checks for one specific ppro bug.
On a 386 this funtion returns 0.
This is part of the (optional) part of this patch that selects only the
needed parts in arch/i386/kernel/cpu/Makefile. When compiling a kernel
without any support for Intel CPUs I got a linker error. It could be
CONFIG_CPU_INTEL (since that's when arch/i386/kernel/cpu/intel.c gets
compiled) but since this function returns 1 only for some ppro's I've
optimized it to ppro_with_ram_bug.
> > static void __init init_ifs(void)
> > {
> > +
> > +#if defined(CONFIG_CPU_K6)
> > amd_init_mtrr();
> > +#endif
> > +
> > +#if defined(CONFIG_CPU_586)
> > cyrix_init_mtrr();
> > +#endif
> > +
> > +#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
> > centaur_init_mtrr();
> > +#endif
> > +
>
> For the handful of bytes saved in the mtrr driver, I'm more concerned
> about ifdef noise, and the fact that we don't have a compile once-run
> everywhere MTRR driver anymore unless you pick your options right
You have a "compile once-run everywhere MTRR driver" if you select all
CPUs.
As stated above, this isn't part of the core patch.
> Dave
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, Sep 13, 2003 at 06:41:46PM +0200, Adrian Bunk wrote:
> > > In 2.6 selecting M486 means that only the 486 is supported.
> >
> > What are you basing this on ? This seems bogus to me.
> > Last I checked, I could for eg, boot a 386 kernel on an Athlon.
>
> It currently works.
Exactly, then your first statement above is bogus.
> The question is the exact semantics of X86_GENERIC.
> If you read the description of X86_GENERIC it implicitely says a kernel
> for a 386 isn't generic.
Apart from using incorrect cache line alignments on P4, an i386 kernel
is no more, no less generic than one compiled with X86_GENERIC
> > > +config CPU_VIAC3_2
> > > bool "VIA C3-2 (Nehemiah)"
> > > help
> > > - Select this for a VIA C3 "Nehemiah". Selecting this enables usage
> > > - of SSE and tells gcc to treat the CPU as a 686.
> > > - Note, this kernel will not boot on older (pre model 9) C3s.
> > > + Select this for a VIA C3 "Nehemiah" (model 9 and above).
> >
> > You lost an important part of helptext.
> With the patch to the Makefile the "enables usage of SSE and tells gcc
> to treat the CPU as a 686" is only true if you don't compile support for
> older CPUs.
Incidentally, looking closer you broke this option.
+ifdef CONFIG_CPU_VIAC3_2
+ cpuflags-y := $(call check_gcc,-march=c3,-march=i686)
+endif
Its C3_2 becauase it needs -march=c3-2 to use SSE instead of 3dnow
prefetches. One thing that just occured to me, it may be possible
to dispose of this option completley now that Andi's runtime
patching code is in. If I get time I'll take a look at that.
> > > +ifdef CONFIG_CPU_K8
> > > + ifdef CONFIG_CPU_PENTIUM4
> > > + cpuflags-y := $(call check_gcc,-march=pentium3,-march=i686)
> > > + else
> > > + cpuflags-y := $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
> > > + endif
> > > +endif
> > > +
> >
> > These horrible nesting things are also a real PITA, as theres >1 case
> > that needs updating when something changes for a particular
> > vendor/family. The cflags-$foo stuff in 2.6 was just starting to
> > become readable, and you want to undo that?
>
> The idea is to move the question "Which CPU option supports bot an
> Athlon and a Pentium 4?" from the user to the kernel. The user no longer
> has to take care of this, he simply selects all CPUs he wants to
> support.
That should be solved using CONFIG_X86_GENERIC, not fuglifying the Makefiles.
Seriously, I think this is completely the wrong approach. Seriously, how many
mails does l-k get of people saying, "Oh duh, my no booting kernel was
because I chose to compile for Athlon, and I have a Pentium 4" or the likes?
This seems to be a solution in search of a problem.
> > > -#ifdef CONFIG_MK7
> > > +#ifndef CONFIG_CPU_CYRIXIII
> > >
> > > /*
> > > * The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
> >
> > wtf ?
>
> It's logical considering the dependencies of X86_USE_3DNOW.
>
> But thinking about it a second time, it seems a CONFIG_CPU_ONLY_K7 does
> the same and is less error prone.
X86_USE_3DNOW would seem more logical to me. I never checked if this
was a win on C3, but as that also has 3dnow its possibly worth looking into.
> > > --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old 2003-09-13 14:18:04.000000000 +0200
> > > +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c 2003-09-13 14:23:26.000000000 +0200
> > > @@ -436,8 +436,12 @@
> > > if (!mem_map)
> > > BUG();
> > > #endif
> > > -
> > > +
> > > +#ifdef CONFIG_CPU_686
> > > bad_ppro = ppro_with_ram_bug();
> > > +#else
> > > + bad_ppro = 0;
> > > +#endif
> > >
> >
> > If we boot a 386 kernel on a ppro with that bug, this goes bang.
>
> ppro_with_ram_bug checks for one specific ppro bug.
> On a 386 this funtion returns 0.
I'm not talking about running it on a 386. I'm talking about running
a kernel _compiled as 386_, on a PPro which has the bug this fixes.
With your patch, this code does nothing, and the bug doesn't get worked
around. Currently, it does the right thing. You're saving a half dozen
or so bytes, and making things like vendor boot kernels (typically
compiled as 386) not perform a necessary errata workaround.
And "You can select 486/586/686 too" is not an answer. These kernels
need to be small, and errata workarounds should NEVER be compiled out
for exactly this reason.
> > > static void __init init_ifs(void)
> > > {
> > > +
> > > +#if defined(CONFIG_CPU_K6)
> > > amd_init_mtrr();
> > > +#endif
> > > +
> > > +#if defined(CONFIG_CPU_586)
> > > cyrix_init_mtrr();
> > > +#endif
> > > +
> > > +#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
> > > centaur_init_mtrr();
> > > +#endif
> > > +
> >
> > For the handful of bytes saved in the mtrr driver, I'm more concerned
> > about ifdef noise, and the fact that we don't have a compile once-run
> > everywhere MTRR driver anymore unless you pick your options right
>
> You have a "compile once-run everywhere MTRR driver" if you select all
> CPUs.
That doesn't solve the 'looks ugly as all hell' problem.
Dave
--
Dave Jones http://www.codemonkey.org.uk
On Sat, Sep 13, 2003 at 07:20:00AM -0700, Kevin P. Fleming wrote:
> Adrian Bunk wrote:
>
> >I'd appreciate it if more people could try this patch and report whether
> >their kernel compiles and works.
>
> Compiling with config below produces linking errors:
>
> arch/i386/lib/lib.a(usercopy.o): In function `__copy_to_user_ll':
> usercopy.o(.text+0x279): undefined reference to `movsl_mask'
> arch/i386/lib/lib.a(usercopy.o): In function `__copy_from_user_ll':
> usercopy.o(.text+0x2e9): undefined reference to `movsl_mask'
>
> .config:
>...
Thanks for your report. I found the problem and I'll send an updated
patch soon.
cu
Adrian
BTW: It's easier if you send the complete .config.
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, Sep 13, 2003 at 06:21:30PM +0100, Dave Jones wrote:
> On Sat, Sep 13, 2003 at 06:41:46PM +0200, Adrian Bunk wrote:
>
> > > > In 2.6 selecting M486 means that only the 486 is supported.
> > >
> > > What are you basing this on ? This seems bogus to me.
> > > Last I checked, I could for eg, boot a 386 kernel on an Athlon.
> >
> > It currently works.
>
> Exactly, then your first statement above is bogus.
It was a leftover from a first version where I had a misunderstanding
regarding the exact effects of X86_L1_CACHE_SHIFT.
If it should continue to work as it currently works the description
"Generic x86 support" is _very_ misleading.
What does a user think on which machines a kernel will run after he
enabled the following options?
- "Athlon/Duron/K7"
- "Generic x86 support"
> > The question is the exact semantics of X86_GENERIC.
> > If you read the description of X86_GENERIC it implicitely says a kernel
> > for a 386 isn't generic.
>
> Apart from using incorrect cache line alignments on P4, an i386 kernel
> is no more, no less generic than one compiled with X86_GENERIC
plus X86_INTEL_USERCOPY
> > > > +config CPU_VIAC3_2
> > > > bool "VIA C3-2 (Nehemiah)"
> > > > help
> > > > - Select this for a VIA C3 "Nehemiah". Selecting this enables usage
> > > > - of SSE and tells gcc to treat the CPU as a 686.
> > > > - Note, this kernel will not boot on older (pre model 9) C3s.
> > > > + Select this for a VIA C3 "Nehemiah" (model 9 and above).
> > >
> > > You lost an important part of helptext.
> > With the patch to the Makefile the "enables usage of SSE and tells gcc
> > to treat the CPU as a 686" is only true if you don't compile support for
> > older CPUs.
>
> Incidentally, looking closer you broke this option.
>
> +ifdef CONFIG_CPU_VIAC3_2
> + cpuflags-y := $(call check_gcc,-march=c3,-march=i686)
> +endif
>
> Its C3_2 becauase it needs -march=c3-2 to use SSE instead of 3dnow
> prefetches. One thing that just occured to me, it may be possible
>...
Which gcc does support -march=c3-2 ? gcc 3.3.1 doesn't support it.
That's the reason why I changed this -march setting (as noted in my
changelog).
>...
> > > > -#ifdef CONFIG_MK7
> > > > +#ifndef CONFIG_CPU_CYRIXIII
> > > >
> > > > /*
> > > > * The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
> > >
> > > wtf ?
> >
> > It's logical considering the dependencies of X86_USE_3DNOW.
> >
> > But thinking about it a second time, it seems a CONFIG_CPU_ONLY_K7 does
> > the same and is less error prone.
>
> X86_USE_3DNOW would seem more logical to me. I never checked if this
> was a win on C3, but as that also has 3dnow its possibly worth looking into.
Current -test5 (without my patch) has
config X86_USE_3DNOW
bool
depends on MCYRIXIII || MK7
default y
This #ifdef is there to differenciate between the K7 and the generic MMX
implementation.
> > > > --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old 2003-09-13 14:18:04.000000000 +0200
> > > > +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c 2003-09-13 14:23:26.000000000 +0200
> > > > @@ -436,8 +436,12 @@
> > > > if (!mem_map)
> > > > BUG();
> > > > #endif
> > > > -
> > > > +
> > > > +#ifdef CONFIG_CPU_686
> > > > bad_ppro = ppro_with_ram_bug();
> > > > +#else
> > > > + bad_ppro = 0;
> > > > +#endif
> > > >
> > >
> > > If we boot a 386 kernel on a ppro with that bug, this goes bang.
> >
> > ppro_with_ram_bug checks for one specific ppro bug.
> > On a 386 this funtion returns 0.
>
> I'm not talking about running it on a 386. I'm talking about running
> a kernel _compiled as 386_, on a PPro which has the bug this fixes.
> With your patch, this code does nothing, and the bug doesn't get worked
> around. Currently, it does the right thing. You're saving a half dozen
> or so bytes, and making things like vendor boot kernels (typically
> compiled as 386) not perform a necessary errata workaround.
Well, this is an optional part of my patch. It will be splitted from the
main part.
> And "You can select 486/586/686 too" is not an answer. These kernels
> need to be small, and errata workarounds should NEVER be compiled out
> for exactly this reason.
>...
Why is a kernel compiled with support for all CPUs necessarily much
bigger than a current M386 kernel?
OTOH, why waste space on a 486 for 3DNow! support?
> Dave
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, Sep 13, 2003 at 05:11:49PM +0100, Dave Jones wrote:
>
> > In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs
> > on a 486 and above.
> > In 2.6 selecting M486 means that only the 486 is supported.
>
> What are you basing this on ? This seems bogus to me.
> Last I checked, I could for eg, boot a 386 kernel on an Athlon.
If you know that you're only booting on a 486, why include all the junk
needed solely for later processors?
>
> > +config CPU_ONLY_K7
> > + bool
> > + depends on CPU_K7 && !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
> > +
> > +config CPU_ONLY_K8
> > + bool
> > + depends on CPU_K8 && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
> > +
> > +config CPU_ONLY_WINCHIP
> > + bool
> > + depends on CPU_WINCHIP && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_CYRIXIII && !CPU_VIAC3_2
> > + default y
>
> These are hurrendous. Each time we add support for a new CPU we
> have to update each and every one of these. This won't fly,
> someone *WILL* miss one. We've had this sort of thing happen before,
> and its an accident waiting to happen.
Agreed
> > --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old 2003-09-13 14:18:04.000000000 +0200
> > +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c 2003-09-13 14:23:26.000000000 +0200
> > @@ -436,8 +436,12 @@
> > if (!mem_map)
> > BUG();
> > #endif
> > -
> > +
> > +#ifdef CONFIG_CPU_686
> > bad_ppro = ppro_with_ram_bug();
> > +#else
> > + bad_ppro = 0;
> > +#endif
> >
>
> If we boot a 386 kernel on a ppro with that bug, this goes bang.
Echo my first comment. I think it's fair to make this stuff
fine-grained -- as long as present behavior is preserved. So IMO
fine-grained "I really want this cpu, and this cpu only" stuff really
requires a dependency on CONFIG_EMBEDDED. When !CONFIG_EMBEDDED, for
example, it would define CONFIG_CPU_686 to ensure the required 686
pieces were in place.
I like the general direction of Adrian's patch, and think that moving in
this direction will provide a lot of hidden maintenance _benefits_ after
the initial pain... But. Adrian's patch is a tough thing to get right,
and IMO requires a lot of testing.
> > static void __init init_ifs(void)
> > {
> > +
> > +#if defined(CONFIG_CPU_K6)
> > amd_init_mtrr();
> > +#endif
> > +
> > +#if defined(CONFIG_CPU_586)
> > cyrix_init_mtrr();
> > +#endif
> > +
> > +#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
> > centaur_init_mtrr();
> > +#endif
> > +
>
> For the handful of bytes saved in the mtrr driver, I'm more concerned
> about ifdef noise, and the fact that we don't have a compile once-run
> everywhere MTRR driver anymore unless you pick your options right
The arch/i386/kernel/cpu stuff is so modular, code like the above just
screams for an ->init_mtrr() hook in there. drivers/char/hw_random.c
(portably) depends on VIA RNG's xstore instruction, which implies a
dependency on code and settings in arch/i386/*. So, there's nothing
fundamentally wrong with sticking your fingers in there, IMO...
Jeff
On Sat, Sep 13, 2003 at 02:21:59PM -0400, Jeff Garzik wrote:
> > > In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs
> > > on a 486 and above.
> > > In 2.6 selecting M486 means that only the 486 is supported.
> >
> > What are you basing this on ? This seems bogus to me.
> > Last I checked, I could for eg, boot a 386 kernel on an Athlon.
>
> If you know that you're only booting on a 486, why include all the junk
> needed solely for later processors?
Reread. a kernel _compiled for 386_
Precisely what junk do you mean ?
> > If we boot a 386 kernel on a ppro with that bug, this goes bang.
> Echo my first comment.
Echo 2 lines above. People do use 386 kernels for install kernels
on distros. Removing errata workarounds means distros start randomly
exploding during installs.
Dave
--
Dave Jones http://www.codemonkey.org.uk
On Sat, Sep 13, 2003 at 08:22:12PM +0200, Adrian Bunk wrote:
> What does a user think on which machines a kernel will run after he
> enabled the following options?
> - "Athlon/Duron/K7"
> - "Generic x86 support"
Currently, as you can only choose one of them, it should be obvious.
With your 'you can choose n number of options' patch, it becomes
confusing why there is a generic option at all.
> > > If you read the description of X86_GENERIC it implicitely says a kernel
> > > for a 386 isn't generic.
> > Apart from using incorrect cache line alignments on P4, an i386 kernel
> > is no more, no less generic than one compiled with X86_GENERIC
> plus X86_INTEL_USERCOPY
Sure, but that still doesn't prevent it being used on any system as
a generic kernel.
> > Incidentally, looking closer you broke this option.
> >
> > +ifdef CONFIG_CPU_VIAC3_2
> > + cpuflags-y := $(call check_gcc,-march=c3,-march=i686)
> > +endif
> >
> > Its C3_2 becauase it needs -march=c3-2 to use SSE instead of 3dnow
> > prefetches. One thing that just occured to me, it may be possible
> >...
>
> Which gcc does support -march=c3-2 ? gcc 3.3.1 doesn't support it.
the 3.3.2 and 3.4 branches have it.
> > And "You can select 486/586/686 too" is not an answer. These kernels
> > need to be small, and errata workarounds should NEVER be compiled out
> > for exactly this reason.
> >...
> Why is a kernel compiled with support for all CPUs necessarily much
> bigger than a current M386 kernel?
Adding in stuff like cpu specific memory copy routines for example.
There have been several cases where vendors haven't been able to squeeze a
boot kernel onto a CD by 40 or so bytes in the past, leading to a last
minute scavenge to try and reclaim that space. Every little helps.
> OTOH, why waste space on a 486 for 3DNow! support?
I'm arguing for errata workarounds, not extended support.
Dave
--
Dave Jones http://www.codemonkey.org.uk
On Sad, 2003-09-13 at 19:21, Jeff Garzik wrote:
> If you know that you're only booting on a 486, why include all the junk
> needed solely for later processors?
Because its a nightmare to provide a billion CPU specific kernels, a set
of foo and higher kernels and a "generic kernel", then do it for each
platform 2.6 supports for x86, then test it.
The submission already looks like something out of a puzzle book
On Sat, Sep 13, 2003 at 07:37:58PM +0100, Dave Jones wrote:
> On Sat, Sep 13, 2003 at 02:21:59PM -0400, Jeff Garzik wrote:
>
> > > > In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs
> > > > on a 486 and above.
> > > > In 2.6 selecting M486 means that only the 486 is supported.
> > >
> > > What are you basing this on ? This seems bogus to me.
> > > Last I checked, I could for eg, boot a 386 kernel on an Athlon.
> >
> > If you know that you're only booting on a 486, why include all the junk
> > needed solely for later processors?
>
> Reread. a kernel _compiled for 386_
> Precisely what junk do you mean ?
>
> > > If we boot a 386 kernel on a ppro with that bug, this goes bang.
> > Echo my first comment.
>
> Echo 2 lines above. People do use 386 kernels for install kernels
> on distros. Removing errata workarounds means distros start randomly
> exploding during installs.
You're not understanding the model. I understand your comment about
using 386 kernels for install kernels. If Adrian's patch is done
right, _absolutely nothing should change_ in your described scenario.
Distros would continue doing what they've always done, and would
continue to get the behavior they have always gotten.
Unless you're a power user and select CONFIG_EMBEDDED, of course.
Then behavior changes.
Jeff
On Sad, 2003-09-13 at 19:53, Jeff Garzik wrote:
> You're not understanding the model. I understand your comment about
> using 386 kernels for install kernels. If Adrian's patch is done
> right, _absolutely nothing should change_ in your described scenario.
Duh sorry - althoug Im unconvinced the ifdef explosion is worth it for
the tiny ones (the few hundred byte workarounds)
On Sat, Sep 13, 2003 at 07:35:29PM +0100, Dave Jones wrote:
> On Sat, Sep 13, 2003 at 08:22:12PM +0200, Adrian Bunk wrote:
>
> > What does a user think on which machines a kernel will run after he
> > enabled the following options?
> > - "Athlon/Duron/K7"
> > - "Generic x86 support"
>
> Currently, as you can only choose one of them, it should be obvious.
> With your 'you can choose n number of options' patch, it becomes
> confusing why there is a generic option at all.
No, currently you first choose the CPU. This CPU selection selects most
settings like the CPU features (e.g. enables X86_F00F_BUG) and the gcc
optimization flags.
The "Generic x86 support" question is asked later.
My patch removes the generic option since it's no longer needed.
>...
> > > Incidentally, looking closer you broke this option.
> > >
> > > +ifdef CONFIG_CPU_VIAC3_2
> > > + cpuflags-y := $(call check_gcc,-march=c3,-march=i686)
> > > +endif
> > >
> > > Its C3_2 becauase it needs -march=c3-2 to use SSE instead of 3dnow
> > > prefetches. One thing that just occured to me, it may be possible
> > >...
> >
> > Which gcc does support -march=c3-2 ? gcc 3.3.1 doesn't support it.
>
> the 3.3.2 and 3.4 branches have it.
Ah I didn't know that. The 20030831 snapshot of the 3.3 branch in Debian
unstable was the latest gcc I checked.
> > > And "You can select 486/586/686 too" is not an answer. These kernels
> > > need to be small, and errata workarounds should NEVER be compiled out
> > > for exactly this reason.
> > >...
> > Why is a kernel compiled with support for all CPUs necessarily much
> > bigger than a current M386 kernel?
>
> Adding in stuff like cpu specific memory copy routines for example.
> There have been several cases where vendors haven't been able to squeeze a
> boot kernel onto a CD by 40 or so bytes in the past, leading to a last
> minute scavenge to try and reclaim that space. Every little helps.
>
> > OTOH, why waste space on a 486 for 3DNow! support?
>
> I'm arguing for errata workarounds, not extended support.
I'll send the cpu selection patch with the arch/i386/kernel/cpu/ and
arch/i386/kernel/cpu/mtrr/ stuff as separate patches.
> Dave
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, Sep 13, 2003 at 02:53:19PM -0400, Jeff Garzik wrote:
> >
> > Echo 2 lines above. People do use 386 kernels for install kernels
> > on distros. Removing errata workarounds means distros start randomly
> > exploding during installs.
>
> You're not understanding the model. I understand your comment about
> using 386 kernels for install kernels. If Adrian's patch is done
> right, _absolutely nothing should change_ in your described scenario.
>
> Distros would continue doing what they've always done, and would
> continue to get the behavior they have always gotten.
>...
I'm not sure whether you understand my intention.
Nothing will change, except that if you want to support all CPUs, you
have to select all CPUs instead of 386.
My main intention is to get a clear user interface (user = person
compiling the kernel) that suits everyone's needs and to put all the
logic what to do when you plan to support several different CPUs into
the kernel.
I don't like the current user interface that says "if you want to
support both an Athlon and a Pentium 4 in your kernel use the Pentium III
option. And for better optimization, also check the "generic" option".
> Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
> I'm not sure whether you understand my intention.
>
> Nothing will change, except that if you want to support all CPUs, you
> have to select all CPUs instead of 386.
This is incorrect. You don't want to change the behavior that people
are relying on. I wasn't describing your intentions, I was describing
what you _should_ do ;-)
Jeff
Adrian Bunk <[email protected]> writes:
>
> I don't like the current user interface that says "if you want to
> support both an Athlon and a Pentium 4 in your kernel use the Pentium III
> option. And for better optimization, also check the "generic" option".
The big issue with your ifdefing of workarounds is that it causes subtle
support problems. A lot of settings for specific CPUs boot and work
fine on other CPUs (possibly with small performance impact, but they're
rarely noticeable without explicit benchmarking). Just when you don't
include the workarounds for the bugs on these other CPUs it will boot and
even run, but fail mysteriously once a month. And that would be a support
nightmare.
-Andi
On Sun, 14 Sep 2003, Andi Kleen wrote:
> Adrian Bunk <[email protected]> writes:
> >
> > I don't like the current user interface that says "if you want to
> > support both an Athlon and a Pentium 4 in your kernel use the Pentium III
> > option. And for better optimization, also check the "generic" option".
>
> The big issue with your ifdefing of workarounds is that it causes subtle
> support problems. A lot of settings for specific CPUs boot and work
> fine on other CPUs (possibly with small performance impact, but they're
> rarely noticeable without explicit benchmarking). Just when you don't
> include the workarounds for the bugs on these other CPUs it will boot and
> even run, but fail mysteriously once a month. And that would be a support
> nightmare.
>
it sounds like a nessasary part of this patch would be to detect the CPU
type and complain VERY loudly if it's not one supported by the build.
This is probably a good idea anyway.
David Lang
> > > I don't like the current user interface that says "if you want to
> > > support both an Athlon and a Pentium 4 in your kernel use the Pentium III
> > > option. And for better optimization, also check the "generic" option".
If we go with the bitmap of processors to support idea, the generic option will be unnecessary.
You would then be able to:
* Support, (I.E. include workarounds for, and not include instructions
that are not supported by), as many or as few processors as you
desire.
* Optimise, (I.E. set alignment, and code generation within the subset
of instructions permitted in the 'Support' selection above), for one
specific processor.
> > The big issue with your ifdefing of workarounds is that it causes subtle
> > support problems. A lot of settings for specific CPUs boot and work
> > fine on other CPUs (possibly with small performance impact, but they're
> > rarely noticeable without explicit benchmarking). Just when you don't
> > include the workarounds for the bugs on these other CPUs it will boot and
> > even run, but fail mysteriously once a month. And that would be a support
> > nightmare.
> it sounds like a nessasary part of this patch would be to detect the CPU
> type and complain VERY loudly if it's not one supported by the build.
>
> This is probably a good idea anyway.
It is a good idea for 99% of kernels, but still needs to be configurable.
Maybe the option should not be present in the kernel configurator, and
require manual editing of the .config file to enable it.
John.
> > Nothing will change, except that if you want to support all CPUs, you
> > have to select all CPUs instead of 386.
>
> This is incorrect. You don't want to change the behavior that people
> are relying on.
Does it matter over a major version change? Surely as long as the
help text is sufficiently updated it's OK? Loads of other things have
subtly changed...
John.