Make common x86 arch area for i386 and x86_64 - Take 2

[Hopefully fixed email client to make it to the list this time] [This series has changed by using git-diff -M]

Recently I've been doing some work that will affect both the i386 and x86_64 architectures. So there will be common code for both, as well as code that will be unique for the specific arch. So I was looking into a way to do this cleanly, and found that there is no clean way to share code between x86_64 and i386.

What we have currently is a bunch of hacks. Seems that people can't make up their mind to what to do.

We have hack 1.
===============

Reference code from i386 in the x86_64 Makefiles.

Examples:

therm_throt-y += ../../i386/kernel/cpu/mcheck/therm_throt.o
bootflag-y += ../../i386/kernel/bootflag.o

[tabs screwed up, because the above can't be consistant on that either]

We have hack 2.
===============

Reference code from x86_64 in the i386 Makefiles.

Examples:

k8-y += ../../x86_64/kernel/k8.o
stacktrace-y += ../../x86_64/kernel/stacktrace.o

[again the tabs too are messed up]
[--ok I'm sure I mess up the tabs too in my code--]

Now my favorite hacks!

We have hack 3.
===============

Make a sole file with just an include pointer to the i386 code.

  rostedt@bilbo:~/work/git/linus.git$ cat arch/x86_64/lib/msr-on-cpu.c
  #include "../../i386/lib/msr-on-cpu.c"
  rostedt@bilbo:~/work/git/linus.git$

We have hack 4.
===============

Make a sole file with just an include pointer to the x86_64 code.

  rostedt@bilbo:~/work/git/linus.git$ cat arch/i386/kernel/early_printk.c

  #include "../../x86_64/kernel/early_printk.c"
  rostedt@bilbo:~/work/git/linus.git$

So I spent last night hacking up something to try to make a common ground for all code that is shared between x86_64 and i386. I called this

arch/x86

Seems appropriate, but I really don't care what it's called. One thing about this name, is that typing arch/x86<Tab> doesn't tab complete x86_64 anymore. But if you can think of something better, I'd be happy to apply it.

So the following set of patches moves common code into the arch/x86 area and updates the i386 and x86_64 files accordingly. I separated the patches into files that hold just Makefile changes, Kconfig changes, and the actual moves of files.

The moves are now represted in its own patch, with one big rename patch, using the git-diff -M format.

So the moves are simply renames, with the slight exception
of files that hold the speedstep-lib.h file. This file was moved from the arch/i386/kerne/cpu/cpufreq directory and put into the include/asm-i386 directory. This was due to the fact that some of the moved files included it, and some files that were not moved also included it. Instead of using the #include "../../x86/" hack again, I just simply moved it to the global i386 include directory. Only the arch/x86 will use the include/asm-i386 change. But to make this change the move patches of the files that contain this change also contain the changes to reference the change to locate this file.

With this change of having a single repo that holds both the x86_64 files as well as the i386 code, it becomes obvious of what files are being shared. This way we don't have to worry about someone changing a file in either x86_64 or i386 and having it break the other arch, because they didn't realize it was being shared.

Note: I left out all the shared pci code. It seems that this code is placed special in the Makefiles for linking order or what not, and I don't want to spend the time sorting that out without knowing if these changes are acceptible or not.

-- Steve

PS. Sorry for the spam. I need to figure out how to tame quilt mail!

--

Create a toplevel Kconfig for arch/x86 and update the i386 and x86_64 Kconfigs as well.

new file mode 100644
index 0000000..18223ff
@@ -0,0 +1,4 @@
+
+
+source arch/x86/oprofile/Kconfig
+

index 56eb14c..3a2e117 100644
@@ -738,7 +738,7 @@ source fs/Kconfig
 menu "Instrumentation Support"
         depends on EXPERIMENTAL
 
-source "arch/x86_64/oprofile/Kconfig"
+source "arch/x86/Kconfig"
 
 config KPROBES
 	bool "Kprobes (EXPERIMENTAL)"

--

Create the arch/x86/Makefile and modify the i386 and x86_64 Makefiles accordingly.

new file mode 100644
index 0000000..97407b2
@@ -0,0 +1,3 @@
+
+
+drivers-$(CONFIG_OPROFILE)		+= arch/x86/oprofile/

index bd28f9f..78e59ef 100644
@@ -98,15 +98,17 @@ mflags-y += -Iinclude/asm-i386/mach-default
 
 head-y := arch/i386/kernel/head.o arch/i386/kernel/init_task.o
 
-libs-y 					+= arch/i386/lib/
+libs-y 					+= arch/i386/lib/ \
+					   arch/x86/lib/
 core-y					+= arch/i386/kernel/ \
+					   arch/x86/kernel/ \
 					   arch/i386/mm/ \
+					   arch/x86/mm/ \
 					   arch/i386/$(mcore-y)/ \
 					   arch/i386/crypto/
 drivers-$(CONFIG_MATH_EMULATION)	+= arch/i386/math-emu/
 drivers-$(CONFIG_PCI)			+= arch/i386/pci/
 # must be linked after kernel/
-drivers-$(CONFIG_OPROFILE)		+= arch/i386/oprofile/
 drivers-$(CONFIG_PM)			+= arch/i386/power/
 
 CFLAGS += $(mflags-y)

index 2941a91..150942b 100644
@@ -79,11 +79,15 @@ head-y := arch/x86_64/kernel/head.o arch/x86_64/kernel/head64.o arch/x86_64/kern
 
 libs-y 					+= arch/x86_64/lib/
 core-y					+= arch/x86_64/kernel/ \
+					   arch/x86/kernel/ \
 					   arch/x86_64/mm/ \
-					   arch/x86_64/crypto/
+					   arch/x86/mm/ \
+					   arch/x86_64/crypto/ \
+					   arch/x86/lib/
 core-$(CONFIG_IA32_EMULATION)		+= arch/x86_64/ia32/
 drivers-$(CONFIG_PCI)			+= arch/x86_64/pci/
-drivers-$(CONFIG_OPROFILE)		+= arch/x86_64/oprofile/
+
+include arch/x86/Makefile
 
 boot := arch/x86_64/boot
 

--

Create the arch/x86/acpi/Makefile, and remove the associate stuff from the i386 and x86_64.

new file mode 100644
index 0000000..f4aa6dc
@@ -0,0 +1,5 @@
+obj-$(CONFIG_ACPI)		+= boot.o
+
+ifneq ($(CONFIG_ACPI_PROCESSOR),)
+obj-y		+= processor.o cstate.o
+endif

index 080b996..eb4bc11 100644
@@ -1,9 +1,2 @@
-obj-y			:= boot.o
-boot-y			:= ../../../i386/kernel/acpi/boot.o
 obj-$(CONFIG_ACPI_SLEEP)	+= sleep.o wakeup.o
 
-ifneq ($(CONFIG_ACPI_PROCESSOR),)
-obj-y			+= processor.o
-processor-y		:= ../../../i386/kernel/acpi/processor.o ../../../i386/kernel/acpi/cstate.o
-endif
-

--

Create the arch/x86/kernel/cpu/cpufreq/Makefile and update the i386 and x86_64 accordingly.

new file mode 100644
index 0000000..51b32fe
@@ -0,0 +1,6 @@
+
+obj-$(CONFIG_X86_POWERNOW_K8) += powernow-k8.o
+obj-$(CONFIG_X86_ACPI_CPUFREQ) += acpi-cpufreq.o
+obj-$(CONFIG_X86_SPEEDSTEP_CENTRINO) += speedstep-centrino.o
+obj-$(CONFIG_X86_P4_CLOCKMOD) += p4-clockmod.o
+obj-$(CONFIG_X86_SPEEDSTEP_LIB) += speedstep-lib.o

deleted file mode 100644
index 753ce1d..0000000
@@ -1,17 +0,0 @@
-#
-# Reuse the i386 cpufreq drivers
-#
-
-SRCDIR := ../../../i386/kernel/cpu/cpufreq
-
-obj-$(CONFIG_X86_POWERNOW_K8) += powernow-k8.o
-obj-$(CONFIG_X86_ACPI_CPUFREQ) += acpi-cpufreq.o
-obj-$(CONFIG_X86_SPEEDSTEP_CENTRINO) += speedstep-centrino.o
-obj-$(CONFIG_X86_P4_CLOCKMOD) += p4-clockmod.o
-obj-$(CONFIG_X86_SPEEDSTEP_LIB) += speedstep-lib.o
-
-powernow-k8-objs := ${SRCDIR}/powernow-k8.o
-speedstep-centrino-objs := ${SRCDIR}/speedstep-centrino.o
-acpi-cpufreq-objs := ${SRCDIR}/acpi-cpufreq.o
-p4-clockmod-objs := ${SRCDIR}/p4-clockmod.o
-speedstep-lib-objs := ${SRCDIR}/speedstep-lib.o

index 560f776..49c4ca4 100644
@@ -1,6 +1,6 @@
+# See also arch/x86/kernel/cpu/cpufreq/Makefile
 obj-$(CONFIG_X86_POWERNOW_K6)		+= powernow-k6.o
 obj-$(CONFIG_X86_POWERNOW_K7)		+= powernow-k7.o
-obj-$(CONFIG_X86_POWERNOW_K8)		+= powernow-k8.o
 obj-$(CONFIG_X86_LONGHAUL)		+= longhaul.o
 obj-$(CONFIG_X86_E_POWERSAVER)		+= e_powersaver.o
 obj-$(CONFIG_ELAN_CPUFREQ)		+= elanfreq.o

@@ -8,9 +8,5 @@ obj-$(CONFIG_SC520_CPUFREQ)		+= sc520_freq.o
 obj-$(CONFIG_X86_LONGRUN)		+= longrun.o  
 obj-$(CONFIG_X86_GX_SUSPMOD)		+= gx-suspmod.o
 obj-$(CONFIG_X86_SPEEDSTEP_ICH)		+= speedstep-ich.o
-obj-$(CONFIG_X86_SPEEDSTEP_LIB)		+= speedstep-lib.o
 obj-$(CONFIG_X86_SPEEDSTEP_SMI)		+= speedstep-smi.o
-obj-$(CONFIG_X86_ACPI_CPUFREQ)		+= acpi-cpufreq.o
-obj-$(CONFIG_X86_SPEEDSTEP_CENTRINO)	+= speedstep-centrino.o
-obj-$(CONFIG_X86_P4_CLOCKMOD)		+= p4-clockmod.o
 obj-$(CONFIG_X86_CPUFREQ_NFORCE2)	+= cpufreq-nforce2.o

--

Move kernel/cpu/cpufreq/p4-clockmod.c to the common hold.

Also has the slight change to reference speedstep-lib.h that is being moved to include/asm-i386.

similarity index 100%
rename from arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
rename to arch/x86/kernel/cpu/cpufreq/p4-clockmod.c
index 4786fed..ac5d5a1 100644
@@ -33,7 +33,7 @@
 #include <asm/msr.h>
 #include <asm/timex.h>
 
-#include "speedstep-lib.h"
+#include <asm-i386/speedstep-lib.h>
 
 #define PFX	"p4-clockmod: "
 #define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "p4-clockmod", msg)

--

OK, this one is a little different.

Move arch/i386/kernel/cpu/cpufreq/speedstep-lib.h to include/asm-i386.h

This file is used by files in arch/i386/kernel/cpu/cpufreq that are not moved. So we move it into a more global area, to keep the includes from going a bit crazy.

Note, the moved files that include this file will have the change to locate it. So it's not just a straight copy.

similarity index 100%
rename from arch/i386/kernel/cpu/cpufreq/speedstep-lib.h
rename to include/asm-i386/speedstep-lib.h

--

Move kernel/cpu/cpufreq/speedstep-lib.c to the common hold.

Also has the slight change to reference speedstep-lib.h that is being moved to include/asm-i386.

similarity index 100%
rename from arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
rename to arch/x86/kernel/cpu/cpufreq/speedstep-lib.c
index d59277c..ff4482b 100644
@@ -17,7 +17,7 @@
 #include <linux/slab.h>
 
 #include <asm/msr.h>
-#include "speedstep-lib.h"
+#include <asm-i386/speedstep-lib.h>
 
 #define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "speedstep-lib", msg)
 

--

Create the Makefile in the common hold and adjust the i386 and x86_64 code accordingly.

new file mode 100644
index 0000000..bf4ae59
@@ -0,0 +1,5 @@
+
+obj-$(CONFIG_MTRR)	+= 	mtrr/
+obj-y				+= intel_cacheinfo.o
+obj-$(CONFIG_X86_MCE)	+=	mcheck/
+obj-$(CONFIG_CPU_FREQ)	+=	cpufreq/

index 010aecf..e484d74 100644
@@ -8,12 +8,11 @@ obj-y	+=	amd.o
 obj-y	+=	cyrix.o
 obj-y	+=	centaur.o
 obj-y	+=	transmeta.o
-obj-y	+=	intel.o intel_cacheinfo.o
+obj-y	+=	intel.o
 obj-y	+=	rise.o
 obj-y	+=	nexgen.o
 obj-y	+=	umc.o
 
 obj-$(CONFIG_X86_MCE)	+=	mcheck/
 
-obj-$(CONFIG_MTRR)	+= 	mtrr/
 obj-$(CONFIG_CPU_FREQ)	+=	cpufreq/

--

Create the Makefile in the common hold and adjust the i386 and x86_64 code accordingly.

new file mode 100644
index 0000000..6e7cb4c
@@ -0,0 +1 @@
+obj-y	= therm_throt.o
\ No newline at end of file

index f1ebe1c..30808f3 100644
@@ -1,2 +1,2 @@
-obj-y	=	mce.o k7.o p4.o p5.o p6.o winchip.o therm_throt.o
+obj-y	=	mce.o k7.o p4.o p5.o p6.o winchip.o
 obj-$(CONFIG_X86_MCE_NONFATAL)	+=	non-fatal.o

--

Create the arch/x86/kernel/Makefile and change the i386 and x86_64 Makefiles accordingly.

new file mode 100644
index 0000000..e2300ad
@@ -0,0 +1,18 @@
+
+obj-y			+= bootflag.o topology.o quirks.o i8237.o alternative.o \
+			   pcspeaker.o
+
+obj-$(CONFIG_STACKTRACE)	+= stacktrace.o
+
+obj-y			+=	cpu/
+obj-$(CONFIG_X86_MSR)		+= msr.o
+obj-$(CONFIG_MICROCODE)		+= microcode.o
+obj-$(CONFIG_X86_CPUID)		+= cpuid.o
+obj-$(CONFIG_ACPI)		+= acpi/
+obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
+
+ifeq ($(CONFIG_X86_VOYAGER), )
+obj-$(CONFIG_SMP)		+= tsc_sync.o
+endif
+
+obj-$(CONFIG_K8_NB)		+= k8.o

index 4ae3dcf..bea2137 100644
@@ -6,19 +6,15 @@ extra-y := head.o init_task.o vmlinux.lds
 
 obj-y	:= process.o signal.o entry.o traps.o irq.o \
 		ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_i386.o \
-		pci-dma.o i386_ksyms.o i387.o bootflag.o e820.o\
-		quirks.o i8237.o topology.o alternative.o i8253.o tsc.o
+		pci-dma.o i386_ksyms.o i387.o  e820.o\
+		i8253.o tsc.o
 
-obj-$(CONFIG_STACKTRACE)	+= stacktrace.o
 obj-y				+= cpu/
 obj-y				+= acpi/
 obj-$(CONFIG_X86_BIOS_REBOOT)	+= reboot.o
 obj-$(CONFIG_MCA)		+= mca.o
-obj-$(CONFIG_X86_MSR)		+= msr.o
-obj-$(CONFIG_X86_CPUID)		+= cpuid.o
-obj-$(CONFIG_MICROCODE)		+= microcode.o
 obj-$(CONFIG_APM)		+= apm.o
-obj-$(CONFIG_X86_SMP)		+= smp.o smpboot.o tsc_sync.o
+obj-$(CONFIG_X86_SMP)		+= smp.o smpboot.o
 obj-$(CONFIG_X86_TRAMPOLINE)	+= trampoline.o
 obj-$(CONFIG_X86_MPPARSE)	+= mpparse.o
 obj-$(CONFIG_X86_LOCAL_APIC)	+= apic.o nmi.o

@@ -35,13 +31,10 @@ obj-$(CONFIG_ACPI_SRAT) 	+= srat.o
 obj-$(CONFIG_EFI) 		+= efi.o efi_stub.o
 obj-$(CONFIG_DOUBLEFAULT) 	+= doublefault.o
 obj-$(CONFIG_VM86)		+= vm86.o
-obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 obj-$(CONFIG_HPET_TIMER) 	+= hpet.o
-obj-$(CONFIG_K8_NB)		+= k8.o
 
 obj-$(CONFIG_VMI)		+= vmi.o vmitime.o
 obj-$(CONFIG_PARAVIRT)		+= paravirt.o
-obj-y				+= pcspeaker.o
 
 EXTRA_AFLAGS   := -traditional
 

@@ -82,7 +75,3 @@ SYSCFLAGS_vsyscall-syms.o = -r
 $(obj)/vsyscall-syms.o: $(src)/vsyscall.lds \
 			$(obj)/vsyscall-sysenter.o $(obj)/vsyscall-note.o FORCE
 	$(call if_changed,syscall)
-
-k8-y                      += ../../x86_64/kernel/k8.o
-stacktrace-y		  += ../../x86_64/kernel/stacktrace.o
-

index bb47e86..3f10fe0 100644
@@ -7,19 +7,14 @@ EXTRA_AFLAGS	:= -traditional
 obj-y	:= process.o signal.o entry.o traps.o irq.o \
 		ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_x86_64.o \
 		x8664_ksyms.o i387.o syscall.o vsyscall.o \
-		setup64.o bootflag.o e820.o reboot.o quirks.o i8237.o \
-		pci-dma.o pci-nommu.o alternative.o hpet.o tsc.o
+		setup64.o e820.o reboot.o \
+		pci-dma.o pci-nommu.o hpet.o tsc.o
 
-obj-$(CONFIG_STACKTRACE)	+= stacktrace.o
-obj-$(CONFIG_X86_MCE)		+= mce.o therm_throt.o
+obj-$(CONFIG_X86_MCE)		+= mce.o
 obj-$(CONFIG_X86_MCE_INTEL)	+= mce_intel.o
 obj-$(CONFIG_X86_MCE_AMD)	+= mce_amd.o
-obj-$(CONFIG_MTRR)		+= ../../i386/kernel/cpu/mtrr/
 obj-$(CONFIG_ACPI)		+= acpi/
-obj-$(CONFIG_X86_MSR)		+= msr.o
-obj-$(CONFIG_MICROCODE)		+= microcode.o
-obj-$(CONFIG_X86_CPUID)		+= cpuid.o
-obj-$(CONFIG_SMP)		+= smp.o smpboot.o trampoline.o tsc_sync.o
+obj-$(CONFIG_SMP)		+= smp.o smpboot.o trampoline.o
 obj-y				+= apic.o  nmi.o
 obj-y				+= io_apic.o mpparse.o \
 		genapic.o genapic_cluster.o genapic_flat.o

@@ -27,34 +22,15 @@ obj-$(CONFIG_KEXEC)		+= machine_kexec.o relocate_kernel.o crash.o
 obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
 obj-$(CONFIG_PM)		+= suspend.o
 obj-$(CONFIG_SOFTWARE_SUSPEND)	+= suspend_asm.o
-obj-$(CONFIG_CPU_FREQ)		+= cpufreq/
-obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 obj-$(CONFIG_IOMMU)		+= pci-gart.o aperture.o
 obj-$(CONFIG_CALGARY_IOMMU)	+= pci-calgary.o tce.o
 obj-$(CONFIG_SWIOTLB)		+= pci-swiotlb.o
 obj-$(CONFIG_KPROBES)		+= kprobes.o
 obj-$(CONFIG_X86_PM_TIMER)	+= pmtimer.o
 obj-$(CONFIG_X86_VSMP)		+= vsmp.o
-obj-$(CONFIG_K8_NB)		+= k8.o
 obj-$(CONFIG_AUDIT)		+= audit.o
 
 obj-$(CONFIG_MODULES)		+= module.o
 obj-$(CONFIG_PCI)		+= early-quirks.o
 
-obj-y				+= topology.o
-obj-y				+= intel_cacheinfo.o
-obj-y				+= pcspeaker.o
-
 CFLAGS_vsyscall.o		:= $(PROFILING) -g0
-
-therm_throt-y                   += ../../i386/kernel/cpu/mcheck/therm_throt.o
-bootflag-y			+= ../../i386/kernel/bootflag.o
-cpuid-$(subst m,y,$(CONFIG_X86_CPUID))  += ../../i386/kernel/cpuid.o
-topology-y                     += ../../i386/kernel/topology.o
-microcode-$(subst m,y,$(CONFIG_MICROCODE))  += ../../i386/kernel/microcode.o
-intel_cacheinfo-y		+= ../../i386/kernel/cpu/intel_cacheinfo.o
-quirks-y			+= ../../i386/kernel/quirks.o
-i8237-y				+= ../../i386/kernel/i8237.o
-msr-$(subst m,y,$(CONFIG_X86_MSR))  += ../../i386/kernel/msr.o
-alternative-y			+= ../../i386/kernel/alternative.o
-pcspeaker-y			+= ../../i386/kernel/pcspeaker.o

--

Remove the C file with just the include that points to the x86_64 early_printk.c file.

deleted file mode 100644
index 92f812b..0000000
@@ -1,2 +0,0 @@
-
-#include "../../x86_64/kernel/early_printk.c"

--

Remove the C file with just the include that points to the x86_64 tsc_sync.c file.

deleted file mode 100644
index 1242462..0000000
@@ -1 +0,0 @@
-#include "../../x86_64/kernel/tsc_sync.c"

--

Create the Makefile in the common hold and adjust the i386 and x86_64 code accordingly.

new file mode 100644
index 0000000..d683d55
@@ -0,0 +1 @@
+obj-$(CONFIG_SMP)	+= msr-on-cpu.o

index 22d8ac5..304f754 100644
@@ -8,4 +8,3 @@ lib-y = checksum.o delay.o usercopy.o getuser.o putuser.o memcpy.o strstr.o \
 
 lib-$(CONFIG_X86_USE_3DNOW) += mmx.o
 
-obj-$(CONFIG_SMP)	+= msr-on-cpu.o

index c943271..8d5f835 100644
@@ -5,7 +5,6 @@
 CFLAGS_csum-partial.o := -funroll-loops
 
 obj-y := io.o iomap_copy.o
-obj-$(CONFIG_SMP)	+= msr-on-cpu.o
 
 lib-y := csum-partial.o csum-copy.o csum-wrappers.o delay.o \
 	usercopy.o getuser.o putuser.o  \

--

Remove the C file with just the include that points to the i386 msr-on-cpu.c file.

deleted file mode 100644
index 47e0ec4..0000000
@@ -1 +0,0 @@
-#include "../../i386/lib/msr-on-cpu.c"

--

Create the Makefile in the common hold and adjust the i386 and x86_64 code accordingly.

new file mode 100644
index 0000000..1b6e922
@@ -0,0 +1 @@
+obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o

index 80908b5..0cb01e6 100644
@@ -5,6 +5,5 @@
 obj-y	:= init.o pgtable.o fault.o ioremap.o extable.o pageattr.o mmap.o
 
 obj-$(CONFIG_NUMA) += discontig.o
-obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
 obj-$(CONFIG_HIGHMEM) += highmem.o
 obj-$(CONFIG_BOOT_IOREMAP) += boot_ioremap.o

index d25ac86..4beaed8 100644
@@ -3,9 +3,6 @@
 #
 
 obj-y	 := init.o fault.o ioremap.o extable.o pageattr.o mmap.o
-obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
 obj-$(CONFIG_NUMA) += numa.o
 obj-$(CONFIG_K8_NUMA) += k8topology.o
 obj-$(CONFIG_ACPI_NUMA) += srat.o
-
-hugetlbpage-y = ../../i386/mm/hugetlbpage.o

--

Merge the oprofile configs.

deleted file mode 100644
index d8a8408..0000000
@@ -1,17 +0,0 @@
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-	  
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-

--

Create the Makefile in the common hold and adjust the i386 and x86_64 code accordingly.

deleted file mode 100644
index 6be3268..0000000
@@ -1,19 +0,0 @@
-#
-# oprofile for x86-64.
-# Just reuse the one from i386. 
-#
-
-obj-$(CONFIG_OPROFILE) += oprofile.o
- 
-DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
-	oprof.o cpu_buffer.o buffer_sync.o \
-	event_buffer.o oprofile_files.o \
-	oprofilefs.o oprofile_stats.o \
-	timer_int.o )
-
-OPROFILE-y := init.o backtrace.o
-OPROFILE-$(CONFIG_X86_LOCAL_APIC) += nmi_int.o op_model_athlon.o op_model_p4.o \
-				     op_model_ppro.o
-OPROFILE-$(CONFIG_X86_IO_APIC)    += nmi_timer_int.o 
-
-oprofile-y = $(DRIVER_OBJS) $(addprefix ../../i386/oprofile/, $(OPROFILE-y))

--

Here's a list of files that were moved from either i386 or x86_64 over to the arch/x86 directory. Since I now used the git-diff -M option (thanks Linus!), and to spare LKML with a lot of patches, I put all the renames that were unmodified (strictly renamed) into this file, with one exception. I put the moving of the speedstep-lib.h file in it's own file to allow for discussion on that, (ok Chris).

similarity index 100%
rename from arch/i386/kernel/acpi/boot.c
rename to arch/x86/kernel/acpi/boot.c

similarity index 100%
rename from arch/i386/kernel/acpi/cstate.c
rename to arch/x86/kernel/acpi/cstate.c

similarity index 100%
rename from arch/i386/kernel/acpi/processor.c
rename to arch/x86/kernel/acpi/processor.c

similarity index 100%
rename from arch/i386/kernel/alternative.c
rename to arch/x86/kernel/alternative.c

similarity index 100%
rename from arch/i386/kernel/bootflag.c
rename to arch/x86/kernel/bootflag.c

similarity index 100%
rename from arch/i386/kernel/cpu/intel_cacheinfo.c
rename to arch/x86/kernel/cpu/intel_cacheinfo.c

similarity index 100%
rename from arch/i386/kernel/cpu/mcheck/therm_throt.c
rename to arch/x86/kernel/cpu/mcheck/therm_throt.c

similarity index 100%
rename from arch/i386/kernel/cpu/mtrr/Makefile
rename to arch/x86/kernel/cpu/mtrr/Makefile

similarity index 100%
rename from arch/i386/kernel/cpu/mtrr/amd.c
rename to arch/x86/kernel/cpu/mtrr/amd.c

similarity index 100%
rename from arch/i386/kernel/cpu/mtrr/centaur.c
rename to arch/x86/kernel/cpu/mtrr/centaur.c

similarity index 100%
rename from arch/i386/kernel/cpu/mtrr/cyrix.c
rename to arch/x86/kernel/cpu/mtrr/cyrix.c

similarity index 100%
rename from arch/i386/kernel/cpu/mtrr/generic.c
rename to arch/x86/kernel/cpu/mtrr/generic.c

similarity index 100%
rename from arch/i386/kernel/cpu/mtrr/if.c
rename to arch/x86/kernel/cpu/mtrr/if.c

similarity index 100%
rename from arch/i386/kernel/cpu/mtrr/main.c
rename to arch/x86/kernel/cpu/mtrr/main.c

similarity index 100%
rename from arch/i386/kernel/cpu/mtrr/mtrr.h
rename to arch/x86/kernel/cpu/mtrr/mtrr.h

similarity index 100%
rename from arch/i386/kernel/cpu/mtrr/state.c
rename to arch/x86/kernel/cpu/mtrr/state.c

similarity index 100%
rename from arch/i386/kernel/cpuid.c
rename to arch/x86/kernel/cpuid.c

similarity index 100%
rename from arch/x86_64/kernel/early_printk.c
rename to arch/x86/kernel/early_printk.c

similarity index 100%
rename from arch/i386/kernel/i8237.c
rename to arch/x86/kernel/i8237.c

similarity index 100%
rename from arch/x86_64/kernel/k8.c
rename to arch/x86/kernel/k8.c

similarity index 100%
rename from arch/i386/kernel/microcode.c
rename to arch/x86/kernel/microcode.c

similarity index 100%
rename from arch/i386/kernel/msr.c
rename to arch/x86/kernel/msr.c

similarity index 100%
rename from arch/i386/kernel/pcspeaker.c
rename to arch/x86/kernel/pcspeaker.c

similarity index 100%
rename from arch/i386/kernel/quirks.c
rename to arch/x86/kernel/quirks.c

similarity index 100%
rename from arch/x86_64/kernel/stacktrace.c
rename to arch/x86/kernel/stacktrace.c

similarity index 100%
rename from arch/i386/kernel/topology.c
rename to arch/x86/kernel/topology.c

similarity index 100%
rename from arch/x86_64/kernel/tsc_sync.c
rename to arch/x86/kernel/tsc_sync.c

similarity index 100%
rename from arch/i386/lib/msr-on-cpu.c
rename to arch/x86/lib/msr-on-cpu.c

similarity index 100%
rename from arch/i386/mm/hugetlbpage.c
rename to arch/x86/mm/hugetlbpage.c

similarity index 100%
rename from arch/i386/oprofile/Kconfig
rename to arch/x86/oprofile/Kconfig

similarity index 100%
rename from arch/i386/oprofile/Makefile
rename to arch/x86/oprofile/Makefile

similarity index 100%
rename from arch/i386/oprofile/backtrace.c
rename to arch/x86/oprofile/backtrace.c

similarity index 100%
rename from arch/i386/oprofile/init.c
rename to arch/x86/oprofile/init.c

similarity index 100%
rename from arch/i386/oprofile/nmi_int.c
rename to arch/x86/oprofile/nmi_int.c

similarity index 100%
rename from arch/i386/oprofile/nmi_timer_int.c
rename to arch/x86/oprofile/nmi_timer_int.c

similarity index 100%
rename from arch/i386/oprofile/op_counter.h
rename to arch/x86/oprofile/op_counter.h

similarity index 100%
rename from arch/i386/oprofile/op_model_athlon.c
rename to arch/x86/oprofile/op_model_athlon.c

similarity index 100%
rename from arch/i386/oprofile/op_model_p4.c
rename to arch/x86/oprofile/op_model_p4.c

similarity index 100%
rename from arch/i386/oprofile/op_model_ppro.c
rename to arch/x86/oprofile/op_model_ppro.c

similarity index 100%
rename from arch/i386/oprofile/op_x86_model.h
rename to arch/x86/oprofile/op_x86_model.h

similarity index 100%
rename from arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
rename to arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c

similarity index 100%
rename from arch/i386/kernel/cpu/cpufreq/powernow-k8.c
rename to arch/x86/kernel/cpu/cpufreq/powernow-k8.c

similarity index 100%
rename from arch/i386/kernel/cpu/cpufreq/powernow-k8.h
rename to arch/x86/kernel/cpu/cpufreq/powernow-k8.h

similarity index 100%
rename from arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
rename to arch/x86/kernel/cpu/cpufreq/speedstep-centrino.c

--

Well, this means that your patch series doesn't actually *compile* as a series.

In other words, it's a pointless series, since the individual patches just generate a non-working kernel, until they have all been applied.

So I really meant that each patch should be generated with "git diff -M", and you'd have a series of patches that are all working and move one part of the tree at a time (with Makefile changes etc integrated).

Also, in case you didn't notice, it's also perfectly fine to have "impure" moves, ie a move that not only renames something, but also changes something (commonly the comments at the top of the file). Maybe you simply didn't have anything like that, but I thought I'd mention it just in case you tried to avoid it on purpose.

The reason I really want the whole series to be compileable is that especially with a lot of people using "git bisect", if you have something that doesn't compile in the middle, not only does it show that the series wasn't a series, it also means that you cannot automate the bisect and you need manual intervention.

Linus

You're right. I should have kept the "RFC/" part, since the reason for breaking it up was more for review and comments than to actually apply.

There were a couple of "impure moves". But those where done with two different commits. So the git-diff -M produced a "pure move" and then a patch against the end result. So no, I didn't put in any effort to make them all "pure" moves. Git did that for me.

I usually do always try to make my patches compile for every patch. But this was a strange case and I wanted it to be more reviewable than compiling at every stage. But if something can be agreed on, I'll make sure my next patch series conforms to the "compile at every stage" rule.

Thanks,

-- Steve

80x86
8086
ia32 <- I'd go with this for lack of more entries on this list.
i486
i86pc <- Solely listed for completes. No Solarisisms in Linux please :p ix86
x32 <- Blame Microsoft for introducing "x64"
x86_32 <- Will interfere with your tabbing.

	cd arch/i386/kernel/;
	ln -s ../../ia32 ia32;

with

	obj-m += ia32/foo.c
and
	#include "ia32/......./foo.h"

a bit nicer IMO, but may not work as intended.

Jan

But the whole point is that this is *not* a 32-bit file.

It's a file *shared* between 32-bit and 64-bit kernels.

Which is why plain "x86" is the right name. Yeah, Intel calls it "IA" these days, but that's just crazy speak (and probably a combination of a reaction against "amd64" and a way to hide the embarrassment that is "ia64" by confusing the naming so much that one day people won't remember that there was _another_ IA that was a total failure).

Linus

NACK. I think the current ways work just fine.

-Andi

Hi,

I am newbie developing a routing application which needs three features;

1. if the fib lookup fails, my application needs to know about using preferably
netlink, -- any direction to some sample code or files in the kernel???

2. I need a counter recording the hits a fib entry is chosen for packet forwarding. Is it the function fn_trie_lookup in file /net/ipv4/fib_trie.c i need to modify and look into?
-- ?? and therefore is it safe to add a int counter in fib_node w/o breaking the build??

2. need to read the entire fib, i.e dump the fib to the user space, -- again any direction to some sample code etc..
i have seen a fn in /source/net/ipv4/fib_frontend.c , which looks like is supposed to dump the routes but not sure how to use it..

line no.581 int inet_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
Also;
fn_trie_dump() in /net/ipv4/fib_trie.c

This could be an inappropriate list for the above questions, if it is request for
some direction on the appropriate mailing list

Appreciate any help.

Thanking you,
Sujay

Fine.

The thing is others and I (and you) are working on getting paravirt_ops working for x86_64. There's a lot of overlap between i386 and x86_64. Right now the i386 is ahead of x86_64 and the code seems to be put more in the arch/i386 arch. So now we are going to introduce a new ../../i386 hack to get to a shared paravirt_shared.c(?). Or do we just continue on keeping the x86_64 as a separate entity, with a lot of duplicate code?

I'm OK with either way. I just wanted to set a standard while it's still early enough to set one.

-- Steve

What would you like exactly to share?

When it makes sense to share the code it can be shared. That is already done today. But the existing Makefile mechanisms work fine for that.

Making sense:
- There is actually a lot of shared code
- The supported hardware is the same (remember x86-64 is only for modern x86 hardware, while i386 has a much longer legacy)
- No ifdefs

-Andi

I'm still working on that. Others have pressured us into consolidating as much usable code for i386 into x86_64. This may turn out not to be too feasible anyway.

Thanks, I'll keep this in mind.

-- Steve

Only do it where it makes sense and is not too intrusive. Redoing the whole port just for lguest64 is probably not a good idea.

-Andi

Well, at some point Xen is going to be 64-bit. We need a 64-bit paravirt_ops, and it looks to me that 90% of the entrypoints will be more or less identical for 32 and 64 bit x86, so it would be unfortunate to not share it.

The existing technique for sharing stuff between 32 and 64 bits is pretty damn ugly, and I think Steven is on to something with this patch. Though I'm definitely sympathetic to the concern that it will break a pile of outstanding patches.

J

i agree. We've recently factored out quite a bit of common code between i386 and x86_64 recently: genirq, gtod/clocksource and clockevents.

and that's how i think unification of architectures should be done: move code into kernel/* and drivers/*, _not_ into another architecture. That way all architectures benefit.

Ingo

But those are things that can mostly be shared across all archs.

I'm OK with it, although I did waste a lot of effort making those patches (But I speak better in C than in English, or any other verbal language, so it wasn't that bad). But if you look at the code that was merged, I'm not sure many other archs will benefit. How many archs use mtrr's? Perhaps these still can go into the drivers directory with a bit of work. Don't know, I'm not that close to that code to be sure, and don't have the time to find out ATM.

But at least there needs to be a more common way to share files between the two archs. Having a file with just a single line of:

#include "../../i386/kernel/mycommoncode.c"

is not that elegant. The make files are, perhaps, a bit better. Another thing that happens a lot with these shared funcs in these files, is finding them . Since "make TAGS" doesn't bother to check i386 when run with ARCH=x86_64. The first time I searched for early_printk while developing i386 took me an hour, since my search scripts don't check other archs (I've changed that since). I thought that the function was one of these macro created functions, and was non-arch specific (didn't look into arch).

So, when creating new shared code, what's the "proper" way?

-- Steve

yeah.

hm. Do you have any numbers handy - what is the end-result of your unification work, how many lines of code were unified, compared to the total body of code in i386 and x86_64?

yeah, that #include file thing for early_printk.c is just gross.

symbolic links perhaps? In that case i'd also introduce a common naming
scheme: x86_early_printk.c - to make sure we know it right away that those files are bi-arch.

Ingo

Well, I wasn't combining code that wasn't already combined :)

Just moving code that was referenced by another arch to a common directory that showed the code is shared.

So, I moved a total of 44 files that were shared. Some of these were in places where a full directory was shared (the mtrr code). And this doesn't count the Makefiles and Kconfig files that were also modified.

There were only three files with the
#include "../../<arch>/<path-to-file>" code.
These three where early_printk.c, tsc_sync.c and msr-on-cpu.c. The rest is referenced by the Makefiles. This still doesn't make it easy to find functions via TAGS or search scripts.

If you looked at the 18/18 patch, it has a list of the moved files, with the exception of the speedstep-lib.h, which was moved in it's own file, and those that referenced that header.

Does the Linux code tree already support sym links? IOW, are there already sym links in the code tree? (/me probably should just look ;)

So should we have an effort to label the shared code that's already shared. As Andi stated, he doesn't like "large scale" renaming since that doesn't "fix a single bug", and will only "just cause pain". Although I disagree if in the long run it will make it easier to work with. Once one knows about the crazy linking going on then it's not much of a problem, but what about all those that will have to go through this learning curve.

The problem I have with the current approach is that it just isn't clean. Yes it "works", but it still is a hack. And if I do need to write code that will be shared among the two archs (still don't know for sure if this will be the case), I would like to have a clean method in doing it. I don't care what the final solution is, as long as it is clean and not a hack.

-- Steve

/usr/src/linux/include/asm -> /usr/src/linux/include/asm-i386

Jan

That's created at build time. But I don't see anywhere in a freshly cloned repo or fresh untar of the linux tarball, where there exists any symbolic links.

-- Steve

There are none.

Symlinks embedded in the source tree tend to be hard to maintain: you can traditionally not send patches to add/change/move/remove them, and not everybody can even import them at all (ie some people have been so damaged by CVS that they maintain their kernels in it - I'm trying my best to be a humanitarian and rid the world of the scourge that is CVS, but I'm not sure I can undo the untold mental damage wrought by it over decades of quiet suffering).

With git, you can track symlinks and send them as patches, but we've not really had a huge reason to do so. They are easy enough to generate from Makefiles if required, and quite often you don't really need to anyway (ie the "symlink" is often just a make rule, like the

	SRCDIR := ../../../i386/kernel/cpu/cpufreq

line I quoted earlier).

So I'd rather not even start using symlinks unless there is some really good reason. We can continue to just use Makefiles.

Linus

Hey, I know! This is a radical idea, but what if we put the name at the head of the file, and called it

arch/x86/kernel/early_printk.c

instead? Then we could teach each of i386 and x86-64 to include it from that area, and we could put other shared files under the same directory hierarchy so that it would be easy to see which ones are shared?

Crazy idea, I know. But I think I saw somebody send out a patch kind of like that, so maybe this common naming scheme could be as simple as just applying a few patches once they got cleaned up and re-organized some more.

Linus

that is nice too, but it has some disadvantages as well in practice. For example i often want to see 'everything' that belongs to an arch in just one subdirectory. That way one can grep it for example, instead of having to grep two separate places. Symlinks would be fine for that, but an explicit split not really i think - unless we can get some really significant chunk of code into that hierarchy, so that it makes functional /sense/ to look at it in isolation.

with the prefix suggestion we can keep these 'shared' files merged in a single, main functional tree (x86_64), but still have them marked in the VFS as being shared. But ... either way is fine to me - no strong feelings, really.

Ingo

You could do both. Have the x86 directory that Linus suggests for shared files, then have the build system generate the symlinks for you.

Could have arch/x86_64/kernel/common arch/x86_64/mm/common etc. symlinks. that point to arch/x86/kernel, arch/x86/mm etc.

This way you know exactly which files are shared and which are not, which is basically impossible without a grep currently. You also get to do a single grep of all arch code. Best of both worlds? Or do I miss something?

SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Symlinks are usually a bad idea because they tend to not work with objdirs. We did that in 2.4.

-Andi

Don't be silly.

Did you even *look* at the patches?

We're talking about things like

	b/arch/x86/kernel/cpu/cpufreq/powernow-k8.h

so please tell me what drugs you are on that say that we should move this into kernel/* and drivers/* and make all architectures benefit. It's *x86* specific, it's just that k8 exists both in 32-bit and 64-bit land.

The file is *already* shared, it's just that right now it is not in a shared location. Right now it is in arch/i386/ (as if it was i386-specific) and then x86-64 includes it with:

arch/x86_64/kernel/cpufreq/Makefile:

	#
	# Reuse the i386 cpufreq drivers
	#
	
	SRCDIR := ../../../i386/kernel/cpu/cpufreq

and anybody who thinks this is "nice" simply has no taste at all.

Linus

yes. I am strongly in favor of sharing code - i recently introduced arch/x86_64/kernel/tsc_sync.c that is shared by i386 too.

So first i wrote a draft email where i told Andi that he's on crack to NACK it so brutally and that we should clearly do arch/x86 ;-)

then i decided to analyze the patches: currently they move 13452 lines of code. i386 is 87847 lines of code, x86_64 is 40978 lines of code, a total of 128825. That means we move about 10% of the code. Not insignificant but not earth-shattering either. With alot more effort (and testing) we could realistically go up to maybe 20% - but that's still a bit low to spread out all the files, isnt it?

in comparison, arch/powerpc is 159099 lines of code, arch/ppc is 106598 lines of code. So the sharing factor is quite a bit higher there. I dont think we could ever reach that with x86.

So i thought it's a better idea to continue with the current more finegrained scheme of sharing some files between the architectures by having arch/x86_64 be the 'main' repository, with i386 inheriting them back, instead of spreading out the files?

but, whichever variant happens, it's certainly fine to me :)

Ingo

Well, I'd like it to be 100% _eventually_, and just unify the architectures.

We've now done that both for S/390 and POWER, and I think in both cases it's been a clear win. So it's not like this is even a radical idea.

The POWER architecture merge was actually done exactly the incremental way, one file or directory at a time, and seemed to work out fine.

So while I'd like 100%, I'd be happy to even just get started with the really obvious stuff. And the stuff that we *already* share certainly fall under that "really obvious" label.

That's really illogical, because historially, i386 was the main one, so you'd have to either:
- have a really strange mix
OR
- move files around just to share them.

So I'd much rather have just a totally new architecture, and hope that we can migrate more and more to it. Whether we ever get to the POWER situation where only some really odd-ball special cases are still using ppc or not, who knows? It might be, for example, that only the odder i386 cases (ie the "non-PC" subarchitectures - Voyager, Summit, NUMAQ and the like) would stay in i386.

There really is almost nothing in i386 that shouldn't be supported on x86-64 too, unless it literally is the actual low-level asm files and vm86 mode support (which in turn is best left as just a config option that would just *depend* on 32-bit, so even that could sanely be represented in a shared tree without any real downside at all).

Linus

ok, having a single bi-arch final tree is indeed intriquing and i didnt realize that you were suggesting that. (I had the impression that arch/x86/ was more of a 'common library' thing, not a target architecture. What felt weird to me was having 3 separate hierarchies - but as long as it's just a temporary state it's OK.)

the x86_64 and i386 trees have diverged quite a bit though, so this will be a major logistical undertaking. And with Andi opposed to fundamentally it it also lacks a bit of manpower i guess :-/

yeah. But this really scares the sh*t out of me. I already tried to unify some of the most fragile lowlevel bits recently: for example the SMP bootup, TSC sync and APIC initialization sequences were totally different on x86 and x86_64. And those kind of random deviations have spread all around the tree. But ... my experience has been pretty
positive: touching both codebases at once tends to dust off old code and tends to fix more bugs. And in the process of doing that we broke Andrew's laptop only half a dozen times! ;) But .. in the long run, it's alot easier to think about unified code. 32-bit x86 will certainly stay with us for at least 10-20 years, and the best model for maintainance is having one codebase.

Another practical complication is that even for modular stuff, sometimes x86_64 has the better code, sometimes i386. But ... the more i think about it the more i like it. -m32 certainly works fine and does the right thing.

Ingo

I'm not fundamentally opposed, just sceptical on the effort:gain ratio.

Not sure -- i'm often glad I don't have to care about all the old 32bit systems on x86-64. I have no problem with modern 32bit x86 systems, but old x86 tends to be very different from new x86. And all the old erratas are scary.

-Andi

the basic dynamics of legacies does not change if we have only 50% of
them: right now x86_64 is just growing its own set of legacies, at the same rate as i386 did it 10 years ago. That makes little difference in
practice: those legacies will quickly necessiate the _same_ kinds of abstractions that allow the flexible injection of hardware-dependent quirks. In another 5 years the x86_64 tree will end up looking and behaving _just like the i386_ tree, the only difference will be less compatibility. (In fact, it will likely look worse because currently our efforts are 50% split between i386 and x86_64, and the random differences between the two arches are wasting developer resources.)

so we might as well unify the two trees and /learn/ from i386's legacies, while integrating them. Those legacies, by the rule of large numbers, will revisit x86_64 too (or have already visited it). We already have per-APIC-version quirks, per CPU model quirks, etc., etc. The main cost of a quirk is the abstraction it necessiates, not the quirk handler itself. (which, once the framework is there, is modular)

Also, 90% of our users are still running 32bit kernels _even on 64-bit capable hardware_, so we might as well prepare ourselves for a really long march towards a pure 64-bit world. (Which will likely never come.)

Ingo

Modern system are much more similar to each other than older systems due to Windows forcing them and they are using much more hardware.

For example we'll never have the tons of weird APIC errata again old platforms had.

And the 64bit APIC code is already much cleaner because of this and this made new work (like Eric's rework which only happened partially on i386) much easier.

Also 64bit doesn't support any weirdnesses like visws,voyager which probably should have been ripped out long ago because they cause large issues in the code and are practically unused (I bet both have userbases I can count on my fingers)

That's not my experience.

That's also not how it works. Typically bug fixes are applied to both.

32bit is not the problem, the problem is old platforms/weird not quite PC platforms (which don't exist in the 64bit world)/very old CPUs. 32bit has some ugly legacies (like vm86) but they are handleable. The old bugs aren't imho.

When a new unified port was done it could be done for modern x86 only, with arch/i386 kept for the old legacy stuff.
That would be fine for me. The trouble is just that I'm not sure that distributions would actually ship it e.g. because not supporting P5s anymore might be still too radical. And if it was not shipped then it would be useless.

Besides it's would be a lot of work and frankly not very interesting work.

-Andi

i think the sanest (and pretty much only) way to do it would be to unify it _now_, in a single atomic step, safely and in a brute-force way:

create arch/x86/

'unify' arch/i386/ and arch/x86_64/ into arch/x86/ by doing a brute-force prefix solution:

arch/i386/kernel/process.c => arch/x86/kernel/x32_process.c
arch/x86_64/kernel/process.c => arch/x86/kernel/x64_process.c

create bi-arch Makefiles and enable the building of each arch.

obviously, for files that are already totally identical across the two arches, the x32_foo.c and x64_foo.c can be changed to foo.c, right away.

nothing else would be done in this step. We'd remove arch/i386/ and arch/x86_64/ after that.

new files for new functionality can only be added if they are bi-arch.

from this first 'brutal', 'flag day' intrusive step on, every further step would be more finegrained and per-file: an x32_bar.c and x64_bar.c file gets merged into bar.c. About 80-90% of our .c files have the same fundamental purpose in both arches, so this setup makes the most sense to me: first move them 'close' to each other and force them to be part of the same basic build architecture, then 'unify' them.

this way we'd also obviously see the costs of not having unified files:
we'd have to change both the x32_ and the x64_ file for the same thing - while when they are unified, only one change is needed. It's easy to forget that when the arch directories are separate.

also, unifying two files will also be quite gratifying: one of the files vanishes, making up for a sail-through-lkml review.

also, this way it's harder for the two trees (and the shared tree) to get out of sync. If we did 3 separate hierarchies we'd have mixed state pretty quickly.

also, having the x32_ and x64_ prefix is a painful daily reminder for all of us changing the architecture that 'this stuff needs to be unified!'.

hm?

Ingo

We would probably stuck with that forever and it just looks ugly. Non paravirt xen uses such a setup and I always hated it.

Besides the architecture is called x86_64

I don't see a problem with step by step unifying what makes sense in the current setup.

-Andi

If you don't like x{32,64}_ suffixes, _{32,64} suffixes would also be a possibility. powerpc/mm/init_32.c for example does it that way.

Jan

Can't we move the shared files into a new shared arch/ subdirectory (ia32_64 or whatever), and have them included from both places? At least then it's obvious they're shared, and it's a migration strategy to the shared arch that you want.

On the downside, it's more ../../.. type stuff. On the upside, they're more cleanly separated and it's apparent what's going on. Seems nicer to me than drivers/ and kernel/ for stuff that's really arch specific, but shared between two arches.

M.

That's *exactly* what the patches do (except it's called "arch/x86", which is clearly the best option - please don't use "ia" _anywhere_ except for "ia64", since that's the only architecture that is really "intel architecture").

Absolutely. I'm agreeing violently. I just suspect not a lot of people really looked at the patches..

Linus

And i860 @)

Well I just see a lot of pain from these patches but I doubt they will avoid any bugs. If people don't compile test both archs they will always likely break on another. There are lots of subtle dependencies that are not expressed in the pathname even after this intrusive operation (e.g. in the includes).

That's just how it is.

If the architecture merging was ever done it would be likely by extending arch/x86_64 to support (modern) 32bit. But this change doesn't bring us any step closer to that goal.

I think it's just aesthetics -- i'm all for aesthetics but only if it gives better software and doesn't impact other people who want to get something real done; neither of this is the case here.

-Andi

Yeah, well (and the i960).. I don't think it's very likely that we'll ever support that in the kernel ;)

(There are others. i432 is the really *classic* intel architecture. It was such a spectacular failure that it's still remembered today, even though it was never actually used).

Well, we'veliterally had bugs because people who modified i386 files didn't even *realize* that they were also used on x86-64.

I do agree that we'd need to look at do the same thing for include files, for the same reason.

Linus

Or that's just how you see it.

Yes, if you don't compile and test on both it can always break on the other arch. But this at least lets a developer know that what they are modifying requires a compile and test on both. The current way is more of a surprise that it breaks another arch. You're changing a file in arch/i386/... and you later get yelled at for breaking x86_64 ?? That's not negligence, that's blame for being ignorant of the interlocking dependencies. Where-as if you change the file in arch/x86 or include/asm-x86, you had better test both architectures.

With the proposed patch set, what can break i386 by modifying something in arch/x86_64, or what can break x86_64 by modifying something in arch/i386? (not counting the unfinished pci shared code).

I'm not so sure about that. It at least gets people aware of the issues. If you expect x86_64 to start encompassing 32bit, then at least have all the files under arch/x86_64 and point the i386 there. Create something like a x86_common directory under arch/x86_64 and have that contain all the code that i386 can also share. Something that makes it cleaner and not the total hacks that we have today.

Look, I sympathize with you. I'm not about to throw these patches at you and then walk away. I'll take responsibility for them (I've been warned by others that this will happen). If there's issues and hardships that cause you pain, feel free to kick some of the work over to me, and I'll help you out. I'll even accept it when you write to me saying "here! this is broken, and I think your arch/x86 crap is the cause. Fix it or else!".

But I don't share your view that this doesn't give better software. And I think what I've done was real work. Hey, I'm fine with keeping this in arch/x86_64, in something called arch/x86_64/x86_common or something. As long as there's a distinct separation of what is shared and obvious that more testing needs to be done if modified.

-- Steve

[...]

Oops, sorry, you did say "in the includes". Yeah, that holds the same crap that I'm talking about.

$ cat include/asm-i386/stacktrace.h
#include <asm-x86_64/stacktrace.h>

Which isn't something that I would like to stay either. So it's just something else that needs to be fixed. Not something that will circumvent what the current patch set is trying to do.

-- Steve

It's a simple and obvious solution that does exactly what it is supposed to do. Why do you call it crap?

-Andi

Yes, it's a simple solution. The reason I called it crap was because it does what the other hacks do. It hides from the developer a dependency that can create bugs in the other arch, and is not IMNSHO clean.

When one works on one arch, you should not need to be worried about breaking other archs when you stay within the arch/ and asm-<arch> directories.

-- Steve

In the future it is likely that x86_64 will significantly deviate from i386. i386 is going to be gradually abandoned because it does not support the ever larger memory sizes and be mainly used for embedded devices. x86_64 is going to acquire more functionality that will not be available for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual memmap support may require a large chunk of virtual memory space that is not available on i386. Its not good to have to deal with i386 issues when doing x86_64 arch development.

It already is in some cases. And I agree more will happen.

The desktop/server user base is quite conservative so that will take a long time, but gradually probably.

What advantage would that have over the current setup?
We already should handle holes between nodes reasonably efficiently and with nonlinear memory even holes inside nodes shouldn't be a problem.

If the great merged architecture ever happens this would be needed anyways. Just basic 32bit support isn't too difficult anyways -- the problem are more the old bugs.

-Andi

It is primarily a performance improvement since the sparsemem table lookups would no longer be necessary and it also streamlines other frequent cacheline uses. These page -> page_struct and vice versa operations are key to the performance of various subsystem among them the slab allocator.

You have to do some sort of lookup anyway, and Andy seemed to have them all folded into one.

Or are you trying to avoid this by going to back to the crud we had in 2.4 where we pretend mem_map is one big array, indexed by pfn with huge sparsely mapped holes in it?

Would be nice to work out (and document somewhere) what the pros and cons of virtual memmap vs sparsemem were - ISTR one of the arguments was extremely sparsely layed out machines, and you needed sparsemem for that. But right now we have 3 solutions, which is not a good situation.

What lookup would you need to do? On x86_64 even the TLB use is hidden by the existing 2M entries for 1-1 mappings.

Yes that the advanced way of doing it rather than adding useless custom lookups.

Please read my posts to linux-mm on that subject. We discussed it last year in detail and the agreement was that the sparsemem crud needs to be taken out. Kame-san posted patches to do that.

From: Christoph Lameter <[email protected]>
Date: Fri, 16 Mar 2007 13:48:58 -0700 (PDT)

Please don't do that, sparsemem works very well on sparc64 and I like the flexibility it gives me.

Or are you just proposing to stop using it on x86_64?

I am not sure what flexibility you are talking about? The modification are to make sparsemem support virtual memmap as one option. See Kame-san's posts. There is no regression here its just cutting out the overhead of sparsmem from within.

From: Christoph Lameter <[email protected]>
Date: Fri, 16 Mar 2007 13:56:13 -0700 (PDT)

I would really appreciate a posting that explains what exactly is going on being sent to linux-arch, this is the first time I myself am even aware of this idea and work.

Thanks.

For starters, you can't do that sparse a mapping on a 32 bit system. I'll let Andy explain the rest of it.

"the agreement"? So Andy agreed to taking it out? Or you and Kame did?

M.

Yes he has already explained it and I am well aware of the difficulties on 32 bit. -> linux-mm archives.

Yes Andy and lots of others. Big discussion that you seem to want me to repeat here.

Stop pointing to archives.

If you cannot give a http pointer to a specific thread, don't bother with the "please real the list" thing AT ALL.

And I'm sorry, "we decided this on linux-mm" doesn't cut it as an explanation _or_ as a "it's already been decided". Many relevant people simply aren't on that mailing list.

Linus

The discussions centred around some patches from Kame which introduced a SPARSMEM sub-model with a virtual memory map. That was a supprisingly clean change which if followed through to its logical conclusion would remove a significant chunk of architecture specific vmemmap implementation from ia64, and (as I understand it) was likely to allow the same to be reused in s390x as well.

SPARSEMEM would still have its useful modes for smaller memory systems.

-apw

From: Christoph Lameter <[email protected]>
Date: Fri, 16 Mar 2007 13:15:38 -0700 (PDT)

If you set the bit range small enough and don't use sparsemem-extreme, the cost is extremely low considering the flexibility you obtain.

There are always going to be holes on large systems, there isn't really a way to avoid this given how addressing is done on those machines.

What flexibility?

Virtual mmap allows holes in the same way as page tables do. These structures were designed for sparseness. I really do not think we should rediscuss the material here that was discussed on linux-mm. The outcome of that was that we will introduce virtual memmap to reduce sparsemem overhead and to increase flexibility.

From: Christoph Lameter <[email protected]>
Date: Fri, 16 Mar 2007 13:52:18 -0700 (PDT)

I don't want to take expensive TLB misses to lookup a page.

Don't force a virtual mapping solution down my throat if that is not what I believe as a platform maintainer works best for me.

TLB misses are extremely expensive on some platforms, that's why I try to make all the critical structures go through the 4MB locked TLB entry for the kernel image, or failing that the 4MB linear mappings at PAGE_OFFSET on sparc64.

Ummm. You are missing key details please look at linux-mm. We will use huge tlb entries for the mmap and its optional.

Exactly. That is why 16M TLB entries speed up the kernel by 4-5% using vmmemmap on ia64. Basically we end up with one TLB per node for the vmemmap which always stays in the cache. No additional lookups. Without vmemmap we still need a 16M TLB for the 1-1 kernel mapping. This jsut cuts out the crud from sparsemem.

Hi Christoph,

Yeah, those are horribly common operations. But, have we actually quantified how sparsemem hurts here? I know that it look on the surface like those lookups should kill you but, as far as I can tell, we've never been able to show that they actually do. We were worried on the NUMAQ that we would see some performance regressions, but it somehow slightly outperformed discontigmem.

Do you have any hard data that shows vmemmap killing sparsemem on some of your workloads? I'd love to try and fix some of the issues if we can dig them up.

One of the reasons I really like sparsemem is that ports to new architectures are something like 100 lines of code, including all of the #defines. It's really ridiculously easy to do. One of the things that I really worry about for vmemmap implementations is how complicated they get to implement. The fact that we can't easily do it for both i386 and x86_64 at the same time speaks to this a bit.

-- Dave

This is a *totally* bogus and idiotic argument.

x86-64 will get new capabilities, BUT IT WILL CONTINUE TO SUPPORT OLD x86-64 machines.

And those machines are basically identical to perfectly regular i386 platforms.

So the whole argument that it would "diverge" is total crap. It obviously won't diverge, simply because the support for old setups is needed on x86-64 *regardless* of whether 32-bit support exists on the same platform or not.

There's a huge difference between divergence and "more capabilities".

Linus

For modern (2001+) i386 platforms sure. The problem is the old and the weird.

There is still some unneeded old platform code on x86-64 that will be removed (although I'm slowly discovering that some like the irq 0 hacks are still needed :/).

i386 support goes much farther back than the earlier x86-64 code supported, not even talking about complications like the weird and fragile subarchs i386 has.

And x86-64 since it supports only modern systems is easier to hack because it's much easier to regression test and only needs to care about reasonably modern hardware. That is for example it has new smpboot and i386 doesn't and has extended per CPU IRQ vectors and i386 doesn't and has new machine check code and i386 doesn't etc.etc.

It was basically a new start in many areas.

-Andi

IA32 = Intel/AMD 32 :)

Jan

Andi, the current ways do *not* work just fine.

I don't understand why you have problems with obvious cleanups. You also nack'ed the file movement to at least make this kind of thing consistent (ie the header file movement in commit 2272b0e03) to at least only have symlinks pointing one way.

The current situation is horrible. We've had bugs simply because people didn't even *realize* that a file in arch/i386/ was also used by x86-64.

Linus

In my experience, the current situation is a pain in the ass.

There are at least 3 different ways how arch/x86_64/ uses arch/i386/ code [1], and at least 2 different ways how arch/i386/ uses arch/x86_64/

So whenever you touch one file in arch/i386/ or arch/x86_64/, there are 5 different ways how this code could be used from the other architecture.

I'd even suggest the following:
- move all files under arch/x86_64/ that are also used under arch/i386/ to arch/i386/ and then
- mv arch/x86_64 arch/i386/mach-x86_64

The associated Makefile and Kconfig changes shouldn't be a problem, and after this it will become much easier to see where code gets used.

cu
Adrian

[1] Steven forgot in his list the fifth one:

obj-$(CONFIG_MTRR) += ../../i386/kernel/cpu/mtrr/

The problem with this variant is that different from the other 4 ways, grep'ing for a filename doesn't find it...

       "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

<snip>

sorry for being so late, but about what it could be called, well, what about common_x86 or common/x86 or something?

<snip>