linux-kernel - Re: arm-allnoconfig error: '__LINUX_ARM_ARCH_

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]

Date:	Sun, 22 Jul 2012 10:01:43 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Fengguang Wu <fengguang.wu@...el.com>
Cc:	Russell King <linux@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: arm-allnoconfig error: '__LINUX_ARM_ARCH__' undeclared

On Sunday 22 July 2012, Fengguang Wu wrote:
> Kernel build failed on arm-allnoconfig:
> 
> include/linux/math64.h:55:15: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
> arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
> arch/arm/include/asm/glue-df.h:99:2: error: #error Unknown data abort handler type
> arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
> 
> Do you think this allnoconfig test meaningful at all?

The allno/mod/yesconfig tests on ARM are somewhat limited in their
usefulness at the moment because they always pick the same platform
type (versatile) and don't really cover the cases that most people
are interested in.

The particular problem with allnoconfig is that the logic to determine
the architecture level depends on at least one platform being selected,
and there are also problems with nommu kernels that tend to not work
if certain other options are not set correctly. 

We can make the nommu case go away if we make hide the option for
non-expert configurations including allnoconfig. I suggested adding
some logic to all the subarch Kconfig files that forces at least
one of the boards to be enabled like the patch below, but a number
of people didn't like it.

For reference, here is what I would use in order to get 'make
allnoconfig' to work on ARM. My impression is at the moment that
we should make a more serious attempt at fixing all the possible
configurations when we get to 'multiplatform' configurations,
because that will be more interesting than doing it just for
the versatile platform.

Signed-off-by: Arnd Bergmann <arnd@...db.de>

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a306d6d..e43e743 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -236,7 +236,7 @@ source "kernel/Kconfig.freezer"
 menu "System Type"

 config MMU
-	bool "MMU-based Paged Memory Management Support"
+	bool "MMU-based Paged Memory Management Support" if EXPERT
 	default y
 	help
 	  Select if you want MMU-based virtualised addressing space
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index c1f38f6..455f20a 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -25,4 +25,13 @@ config MACH_VERSATILE_DT
 	  Include support for the ARM(R) Versatile/PB platform,
 	  using the device tree for discovery

+config MACH_VERSATILE_AUTO
+	def_bool y
+	depends on !ARCH_VERSATILE_PB
+	depends on !MACH_VERSATILE_AB
+	select MACH_VERSATILE_DT
+	help
+	  We autoselect MACH_VERSATILE_DT if both PB and AB are
+	  disabled, to ensure that at least one platform is enabled.
+
 endmenu
--
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/