Skip to contentSkip to conversation

x86: unify arch/x86/kernel/Makefile(s)

RFC PATCH In review Sam Ravnborg 2 participants 6 messages Dec 30, 2007 x86

lore
Share & tools
lore
#0 lore raw

RFC PATCH 1/1 x86: unify arch/x86/kernel/Makefile(s)

Combine the 32 and 64 bit specific Makefiles in one file. While doing so link order was (almost) preserved on 32 bit but on 64 bit link order changed a lot.

Patch was checked with defconfig + allyesconfig builds. The same .o files were linked in these configurations.

To keep readability of the Makefiles a few Kconfig symbols was added/modified and it was checked that they were not used anywhere else.

Cc Thomas Gleixner <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc "H. Peter Anvin" <[email protected]>

---

I do not have a proper test-system so this patch is not boot tested - sorry.
For 32 bit it is low-risk.
For 64 bit it needs to be boot tested - anyone?

Patch is made on top of mm branch of x86 tree.

Sam

 arch/x86/Kconfig            |   10 ++++-
 arch/x86/Kconfig.debug      |    3 +-
 arch/x86/kernel/Makefile    |   93 +++++++++++++++++++++++++++++++++++++++----
 arch/x86/kernel/Makefile_32 |   54 -------------------------
 arch/x86/kernel/Makefile_64 |   52 ------------------------
 5 files changed, 95 insertions(+), 117 deletions(-)
 delete mode 100644 arch/x86/kernel/Makefile_32
 delete mode 100644 arch/x86/kernel/Makefile_64
arch/x86/Kconfig +9 -1
index 581058a..e6fe276 100644
@@ -132,9 +132,17 @@ config GENERIC_PENDING_IRQ
 
 config X86_SMP
 	bool
-	depends on X86_32 && SMP && !X86_VOYAGER
+	depends on SMP && ((X86_32 && !X86_VOYAGER) || X86_64)
 	default y
 
+config X86_32_SMP
+	def_bool y
+	depends on X86_32 && SMP
+
+config X86_64_SMP
+	def_bool y
+	depends on X86_64 && SMP
+
 config X86_HT
 	bool
 	depends on SMP
arch/x86/Kconfig.debug +1 -2
index 77eda46..625e6bf 100644
@@ -75,8 +75,7 @@ config X86_FIND_SMP_CONFIG
 
 config X86_MPPARSE
 	def_bool y
-	depends on X86_LOCAL_APIC && !X86_VISWS
-	depends on X86_32
+	depends on (X86_32 && (X86_LOCAL_APIC && !X86_VISWS)) || X86_64
 
 config DOUBLEFAULT
 	default y
arch/x86/kernel/Makefile +85 -8

94 lines not on this page · raw message

arch/x86/kernel/Makefile_32 deleted +0 -54

54 lines not on this page · raw message

arch/x86/kernel/Makefile_64 deleted +0 -52

52 lines not on this page · raw message

Signature · 1 line
1.5.3.7.1112.g9758e
#1 lore raw
Quoted 10 lines · Sam Ravnborg

Combine the 32 and 64 bit specific Makefiles in one file. While doing so link order was (almost) preserved on 32 bit but on 64 bit link order changed a lot.

Patch was checked with defconfig + allyesconfig builds. The same .o files were linked in these configurations.

To keep readability of the Makefiles a few Kconfig symbols was added/modified and it was checked that they were not used anywhere else.

hm, i agree with this change, but would it be possible to split this up into gradual steps, to change the rules on 64-bit one by one? That would make it much more bisectable. In our experience changes to the link order have a high likelyhood of breaking stuff, as we've got so many implicit initcall dependencies that are not explicitly spelled out.

Ingo

#2 lore raw
Quoted 11 lines · Ingo Molnar
Quoted 10 lines

Combine the 32 and 64 bit specific Makefiles in one file. While doing so link order was (almost) preserved on 32 bit but on 64 bit link order changed a lot.

Patch was checked with defconfig + allyesconfig builds. The same .o files were linked in these configurations.

To keep readability of the Makefiles a few Kconfig symbols was added/modified and it was checked that they were not used anywhere else.

Quoted 6 lines

hm, i agree with this change, but would it be possible to split this up into gradual steps, to change the rules on 64-bit one by one? That would make it much more bisectable. In our experience changes to the link order have a high likelyhood of breaking stuff, as we've got so many implicit initcall dependencies that are not explicitly spelled out.

i've added your full patch meanwhile - maybe we can get away with it.

Still, if you see any easy way to do a straightforward series of ~40 patches that changes one link rule per patch then that would be great and we could add them as an easier-to-bisect replacement for this one large-scope patch.

Ingo

#3 lore raw
Quoted 1 line · Ingo Molnar

i've added your full patch meanwhile - maybe we can get away with it.

i needed the trivial fix below. You did not test-build it on 32-bit it appears :-)

Ingo

---
 arch/x86/Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/Makefile +1 -1
Index: linux-x86.q/arch/x86/Makefile
===================================================================
@@ -106,7 +106,7 @@ KBUILD_CFLAGS += $(call cc-option,-mno-s
 # fcore-y is linked before mcore-y files.
 
 # Default subarch .c files
-mcore-y  := arch/x86/mach-default
+mcore-y  := arch/x86/mach-default/
 
 # Voyager subarch support
 mflags-$(CONFIG_X86_VOYAGER)	:= -Iinclude/asm-x86/mach-voyager
#4 lore raw
Quoted 7 lines · Ingo Molnar
Quoted 1 line · Ingo Molnar

i've added your full patch meanwhile - maybe we can get away with it.

i needed the trivial fix below. You did not test-build it on 32-bit it appears :-)

Had CONFIG_X86_GENERICARCH defined so I did not hit this one - sorry. Thanks for fixing it up.

Sam

#5 lore raw
In reply to Ingo Molnar
Quoted 21 lines · Ingo Molnar
Quoted 11 lines · Ingo Molnar
Quoted 10 lines

Combine the 32 and 64 bit specific Makefiles in one file. While doing so link order was (almost) preserved on 32 bit but on 64 bit link order changed a lot.

Patch was checked with defconfig + allyesconfig builds. The same .o files were linked in these configurations.

To keep readability of the Makefiles a few Kconfig symbols was added/modified and it was checked that they were not used anywhere else.

Quoted 6 lines

hm, i agree with this change, but would it be possible to split this up into gradual steps, to change the rules on 64-bit one by one? That would make it much more bisectable. In our experience changes to the link order have a high likelyhood of breaking stuff, as we've got so many implicit initcall dependencies that are not explicitly spelled out.

Quoted 6 lines

i've added your full patch meanwhile - maybe we can get away with it.

Still, if you see any easy way to do a straightforward series of ~40 patches that changes one link rule per patch then that would be great and we could add them as an easier-to-bisect replacement for this one large-scope patch.

If it turns out to cause troubles I will redo it in a few smaller steps. But I will have to do it by hand so most likely less than 10 steps.

Sam