linux-kernel - [PATCH v2] x86, kconfig: Pick up the .config arch version in 'make oldconfig'

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1306750170.2029.416.camel@i7.infradead.org>
Date:	Mon, 30 May 2011 11:09:29 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: [PATCH v2] x86, kconfig: Pick up the .config arch version in 'make
 oldconfig'

I wasted a bunch of time today because I'd taken a .config from my 
test machine and tried to build it, and the existing setting of 
CONFIG_X86_32 got changed to the host system's bitness which was 
64-bit.

This patch fixes that. Last time I tried to fix this bug, I had 
introduced a regression that broke:

   make ARCH=x86_64 randconfig
   make ARCH=i386 randconfig

type of filtered-randconfig behavior which restricted randconfigs to 
64-bit and 32-bit configs, respectively.

This version fixes that so prior randconfig behavior is maintained,
although if a "filtered randconfig" is desired it seems like it would be
better to actually implement that properly, rather than relying on a
hack which preserves the obsolete 'ARCH=i386' and 'ARCH=x86_64' legacy
just to influence *one* of the many config options that might need to be
hard-coded if you actually want a 'randconfig' that produces a useful
end-result.

Signed-off-by: David Woodhouse <David.Woodhouse@...el.com>
Link: http://lkml.kernel.org/r/1306707270.2029.377.camel@i7.infradead.org

---
v2: Explicitly turn off CONFIG_64BIT in i386_defconfig. The default for
CONFIG_64BIT has *changed* (from n to y) for ARCH=x86, so it needs to be
explicitly turned off or 'make i386_defconfig' will give you 64-bit :)

diff --git a/Makefile b/Makefile
index 123d858..7b3b7c5 100644
--- a/Makefile
+++ b/Makefile
@@ -165,7 +165,8 @@ export srctree objtree VPATH
 # then ARCH is assigned, getting whatever value it gets normally, and 
 # SUBARCH is subsequently ignored.
 
-SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+				  -e s/sun4u/sparc64/ \
 				  -e s/arm.*/arm/ -e s/sa110/arm/ \
 				  -e s/s390x/s390/ -e s/parisc64/parisc/ \
 				  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cc6c53a..1f206b0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1,7 +1,7 @@
 # Select 32 or 64 bit
 config 64BIT
 	bool "64-bit kernel" if ARCH = "x86"
-	default ARCH = "x86_64"
+	default ARCH != "i386"
 	---help---
 	  Say yes to build a 64-bit kernel - formerly known as x86_64
 	  Say no to build a 32-bit kernel - formerly known as i386
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index b02e509..94c2d8c 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -2,7 +2,11 @@
 
 # select defconfig based on actual architecture
 ifeq ($(ARCH),x86)
+  ifeq ($(shell uname -m),x86_64)
+        KBUILD_DEFCONFIG := x86_64_defconfig
+  else
         KBUILD_DEFCONFIG := i386_defconfig
+  endif
 else
         KBUILD_DEFCONFIG := $(ARCH)_defconfig
 endif
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index 6f98726..41cab70 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -1,3 +1,4 @@
+# CONFIG_64BIT is not set
 CONFIG_EXPERIMENTAL=y
 # CONFIG_LOCALVERSION_AUTO is not set
 CONFIG_SYSVIPC=y

-- 
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/