Hi Andrew,
Today's linux-next fails to build (s390 allnoconfig) like this:
In file included from arch/s390/mm/maccess.c:15:
include/linux/gfp.h: In function 'gfp_zonelist':
include/linux/gfp.h:267: error: '__enabled_CONFIG_NUMA' undeclared (first use in this function)
include/linux/gfp.h:267: error: (Each undeclared identifier is reported only once
include/linux/gfp.h:267: error: for each function it appears in.)
include/linux/gfp.h:267: error: '__enabled_CONFIG_NUMA_MODULE' undeclared (first use in this function)
and many more. This also happens in other architectures and configs but
(obviously) not all builds.
Presumably caused by commit 053361e1a072 ("mm: replace NUMA_BUILD with
IS_ENABLED(CONFIG_NUMA)").
--
Cheers,
Stephen Rothwell [email protected]
Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next fails to build (s390 allnoconfig) like this:
>
> In file included from arch/s390/mm/maccess.c:15:
> include/linux/gfp.h: In function 'gfp_zonelist':
> include/linux/gfp.h:267: error: '__enabled_CONFIG_NUMA' undeclared (first use in this function)
> include/linux/gfp.h:267: error: (Each undeclared identifier is reported only once
> include/linux/gfp.h:267: error: for each function it appears in.)
> include/linux/gfp.h:267: error: '__enabled_CONFIG_NUMA_MODULE' undeclared (first use in this function)
>
> and many more. This also happens in other architectures and configs but
> (obviously) not all builds.
>
> Presumably caused by commit 053361e1a072 ("mm: replace NUMA_BUILD with
> IS_ENABLED(CONFIG_NUMA)").
>
Oops, yes, my fault.
'config NUMA' defined in arch-specific Kconfig, some of them does not have it.
Thus Kconfig generates these constants not for all architectures.
config MIGRATION and config COMPACTION already in generic mm/Kconfig
Config NUMA must be defined for all architectures,
otherwise IS_ENABLED(CONFIG_NUMA) does not work.
Some arch-specific Kconfig already has this stub.
This patch adds it to all remaining.
Signed-off-by: Konstantin Khlebnikov <[email protected]>
---
arch/arm/Kconfig | 3 +++
arch/avr32/Kconfig | 2 ++
arch/blackfin/Kconfig | 3 +++
arch/cris/Kconfig | 3 +++
arch/frv/Kconfig | 3 +++
arch/h8300/Kconfig | 3 +++
arch/hexagon/Kconfig | 3 +++
arch/m68k/Kconfig | 3 +++
arch/microblaze/Kconfig | 3 +++
arch/openrisc/Kconfig | 3 +++
arch/parisc/Kconfig | 3 +++
arch/s390/Kconfig | 3 +++
arch/score/Kconfig | 3 +++
arch/um/Kconfig.common | 3 +++
arch/unicore32/Kconfig | 3 +++
arch/xtensa/Kconfig | 3 +++
16 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a48aecc..42d610b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -246,6 +246,9 @@ config MMU
Select if you want MMU-based virtualised addressing space
support by paged memory management. If unsure, say 'Y'.
+config NUMA
+ def_bool n
+
#
# The "ARM system type" choice list is ordered alphabetically by option
# text. Please add new entries in the option alphabetic order.
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index 3dea7231..3d0cd3c 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -69,6 +69,8 @@ config SUBARCH_AVR32B
bool
config MMU
bool
+config NUMA
+ def_bool n
config PERFORMANCE_COUNTERS
bool
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index abe5a9e..9e60636 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -5,6 +5,9 @@ config SYMBOL_PREFIX
config MMU
def_bool n
+config NUMA
+ def_bool n
+
config FPU
def_bool n
diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig
index b3abfb0..85c8271 100644
--- a/arch/cris/Kconfig
+++ b/arch/cris/Kconfig
@@ -2,6 +2,9 @@ config MMU
bool
default y
+config NUMA
+ def_bool n
+
config ZONE_DMA
bool
default y
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index a685910..3a3e3c9 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -64,6 +64,9 @@ config MMU
CPUs support this. Currently only the FR451 has a sufficiently
featured MMU.
+config NUMA
+ def_bool n
+
config FRV_OUTOFLINE_ATOMIC_OPS
bool "Out-of-line the FRV atomic operations"
default n
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 56e890d..2ccd6ff 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -14,6 +14,9 @@ config MMU
bool
default n
+config NUMA
+ def_bool n
+
config SWAP
bool
default n
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 9059e39..c6be112 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -62,6 +62,9 @@ config KTIME_SCALAR
config MMU
def_bool y
+config NUMA
+ def_bool n
+
config TRACE_IRQFLAGS_SUPPORT
def_bool y
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index ae413d4..b5e0e6a 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -84,6 +84,9 @@ config MMU
Select if you want MMU-based virtualised addressing space
support by paged memory management. If unsure, say 'Y'.
+config NUMA
+ def_bool n
+
config MMU_MOTOROLA
bool
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index c8d6efb..c4c1218 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -86,6 +86,9 @@ config NO_MMU
depends on !MMU
default y
+config NUMA
+ def_bool n
+
comment "Boot options"
config CMDLINE_BOOL
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index bc428b5..f3fe483 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -20,6 +20,9 @@ config OPENRISC
config MMU
def_bool y
+config NUMA
+ def_bool n
+
config SYMBOL_PREFIX
string
default ""
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 242a1b7..a4ab0d5 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -27,6 +27,9 @@ config PARISC
config MMU
def_bool y
+config NUMA
+ def_bool n
+
config STACK_GROWSUP
def_bool y
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index d172758..27da802 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -1,6 +1,9 @@
config MMU
def_bool y
+config NUMA
+ def_bool n
+
config ZONE_DMA
def_bool y
diff --git a/arch/score/Kconfig b/arch/score/Kconfig
index 4b28577..ad4d3a1 100644
--- a/arch/score/Kconfig
+++ b/arch/score/Kconfig
@@ -88,6 +88,9 @@ source "init/Kconfig"
config MMU
def_bool y
+config NUMA
+ def_bool n
+
menu "Executable file formats"
source "fs/Kconfig.binfmt"
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index b37ae70..702cbde 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -14,6 +14,9 @@ config MMU
bool
default y
+config NUMA
+ def_bool n
+
config NO_IOMEM
def_bool y
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index eeb8054..6a845d4 100644
--- a/arch/unicore32/Kconfig
+++ b/arch/unicore32/Kconfig
@@ -79,6 +79,9 @@ menu "System Type"
config MMU
def_bool y
+config NUMA
+ def_bool n
+
config ARCH_FPGA
bool
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index 8a3f835..bb52e90 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -46,6 +46,9 @@ source "kernel/Kconfig.freezer"
config MMU
def_bool n
+config NUMA
+ def_bool n
+
config VARIANT_IRQ_SWITCH
def_bool n
Hi Konstantin,
On Fri, 17 Feb 2012 16:08:15 +0400 Konstantin Khlebnikov <[email protected]> wrote:
>
> Config NUMA must be defined for all architectures,
> otherwise IS_ENABLED(CONFIG_NUMA) does not work.
> Some arch-specific Kconfig already has this stub.
> This patch adds it to all remaining.
Why not add it somewhere generic (like mm/Kconfig, maybe) and then it can
be removed from the architecture specific places over time (if necessary
- I am pretty sure it is ok to have it there twice)?
--
Cheers,
Stephen Rothwell [email protected]
Stephen Rothwell wrote:
> Hi Konstantin,
>
> On Fri, 17 Feb 2012 16:08:15 +0400 Konstantin Khlebnikov<[email protected]> wrote:
>>
>> Config NUMA must be defined for all architectures,
>> otherwise IS_ENABLED(CONFIG_NUMA) does not work.
>> Some arch-specific Kconfig already has this stub.
>> This patch adds it to all remaining.
>
> Why not add it somewhere generic (like mm/Kconfig, maybe) and then it can
> be removed from the architecture specific places over time (if necessary
> - I am pretty sure it is ok to have it there twice)?
>
Different architectures has different dependencies for NUMA.
Seems like Kconfig allow config option duplication, but it use default state from first.
If we add "config NUMA\n def_bool n" somewhere in generic Kconfig, default will be n if
Kconfig see this declaration first.
On Fri, Feb 17, 2012 at 05:32:10PM +0400, Konstantin Khlebnikov wrote:
> Stephen Rothwell wrote:
>> Hi Konstantin,
>>
>> On Fri, 17 Feb 2012 16:08:15 +0400 Konstantin Khlebnikov<[email protected]> wrote:
>>>
>>> Config NUMA must be defined for all architectures,
>>> otherwise IS_ENABLED(CONFIG_NUMA) does not work.
>>> Some arch-specific Kconfig already has this stub.
>>> This patch adds it to all remaining.
>>
>> Why not add it somewhere generic (like mm/Kconfig, maybe) and then it can
>> be removed from the architecture specific places over time (if necessary
>> - I am pretty sure it is ok to have it there twice)?
>>
>
> Different architectures has different dependencies for NUMA.
>
> Seems like Kconfig allow config option duplication, but it use default state from first.
> If we add "config NUMA\n def_bool n" somewhere in generic Kconfig, default will be n if
> Kconfig see this declaration first.
Correct.
And as n is default there is no need to specify it.
But please add a help text that explain the symbol - even if it is not
visible in menuconfig.
Sam
On Fri, 17 Feb 2012 16:08:15 +0400
Konstantin Khlebnikov <[email protected]> wrote:
> Config NUMA must be defined for all architectures,
> otherwise IS_ENABLED(CONFIG_NUMA) does not work.
> Some arch-specific Kconfig already has this stub.
> This patch adds it to all remaining.
It would be better to teach IS_ENABLED() to handle this situation. I
don't think there's a way of doing this with cpp :(
This limitation makes IS_ENABLED pretty dangerous, doesn't it? It
makes it very easy to introduce build breakage with unexpected Kconfig
combinations.
Hi Sam,
On Fri, 17 Feb 2012 14:44:04 +0100 Sam Ravnborg <[email protected]> wrote:
>
> > Seems like Kconfig allow config option duplication, but it use default state from first.
> > If we add "config NUMA\n def_bool n" somewhere in generic Kconfig, default will be n if
> > Kconfig see this declaration first.
> Correct.
> And as n is default there is no need to specify it.
> But please add a help text that explain the symbol - even if it is not
> visible in menuconfig.
So does that mean that a simple
config NUMA
bool
help
some help text
in mm/Kconfig will have no effect on the defaults and dependencies if
"config NUMA" is specified elsewhere? (except to add the needed
__enabled_CONFIG_NUMA defines, of course). If that is the case, then
that is what we should add, right?
--
Cheers,
Stephen Rothwell [email protected]
On Fri, Feb 17, 2012 at 21:30, Andrew Morton <[email protected]> wrote:
> On Fri, 17 Feb 2012 16:08:15 +0400
> Konstantin Khlebnikov <[email protected]> wrote:
>
>> Config NUMA must be defined for all architectures,
>> otherwise IS_ENABLED(CONFIG_NUMA) does not work.
>> Some arch-specific Kconfig already has this stub.
>> This patch adds it to all remaining.
>
> It would be better to teach IS_ENABLED() to handle this situation. I
> don't think there's a way of doing this with cpp :(
>
> This limitation makes IS_ENABLED pretty dangerous, doesn't it? It
> makes it very easy to introduce build breakage with unexpected Kconfig
> combinations.
Indeed. Recently I discovered IS_ENABLED() and started recommending it
to people for new code. But now I've seen the CONFIG_NUMA breakage,
I no longer think this is a good recommendation.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 02/19/2012 09:01 AM, Geert Uytterhoeven wrote:
> On Fri, Feb 17, 2012 at 21:30, Andrew Morton<[email protected]> wrote:
>> On Fri, 17 Feb 2012 16:08:15 +0400
>> Konstantin Khlebnikov<[email protected]> wrote:
>>
>>> Config NUMA must be defined for all architectures,
>>> otherwise IS_ENABLED(CONFIG_NUMA) does not work.
>>> Some arch-specific Kconfig already has this stub.
>>> This patch adds it to all remaining.
>>
>> It would be better to teach IS_ENABLED() to handle this situation. I
>> don't think there's a way of doing this with cpp :(
>>
>> This limitation makes IS_ENABLED pretty dangerous, doesn't it? It
>> makes it very easy to introduce build breakage with unexpected Kconfig
>> combinations.
>
> Indeed. Recently I discovered IS_ENABLED() and started recommending it
> to people for new code. But now I've seen the CONFIG_NUMA breakage,
> I no longer think this is a good recommendation.
adding Michal & linux-kbuild to cc: list.
--
~Randy
Hi Andrew,
On Fri, 17 Feb 2012 21:20:37 +1100 Stephen Rothwell <[email protected]> wrote:
>
> Today's linux-next fails to build (s390 allnoconfig) like this:
>
> In file included from arch/s390/mm/maccess.c:15:
> include/linux/gfp.h: In function 'gfp_zonelist':
> include/linux/gfp.h:267: error: '__enabled_CONFIG_NUMA' undeclared (first use in this function)
> include/linux/gfp.h:267: error: (Each undeclared identifier is reported only once
> include/linux/gfp.h:267: error: for each function it appears in.)
> include/linux/gfp.h:267: error: '__enabled_CONFIG_NUMA_MODULE' undeclared (first use in this function)
>
> and many more. This also happens in other architectures and configs but
> (obviously) not all builds.
>
> Presumably caused by commit 053361e1a072 ("mm: replace NUMA_BUILD with
> IS_ENABLED(CONFIG_NUMA)").
I have removed that patch from the akpm tree until a solution is worked out.
Everything seemed to rebase ok with out it and I can't see much actually
depending on it.
--
Cheers,
Stephen Rothwell [email protected]
On Mon, 20 Feb 2012 10:04:36 +1100 Stephen Rothwell <[email protected]> wrote:
> Hi Andrew,
>
> On Fri, 17 Feb 2012 21:20:37 +1100 Stephen Rothwell <[email protected]> wrote:
> >
> > Today's linux-next fails to build (s390 allnoconfig) like this:
> >
> > In file included from arch/s390/mm/maccess.c:15:
> > include/linux/gfp.h: In function 'gfp_zonelist':
> > include/linux/gfp.h:267: error: '__enabled_CONFIG_NUMA' undeclared (first use in this function)
> > include/linux/gfp.h:267: error: (Each undeclared identifier is reported only once
> > include/linux/gfp.h:267: error: for each function it appears in.)
> > include/linux/gfp.h:267: error: '__enabled_CONFIG_NUMA_MODULE' undeclared (first use in this function)
> >
> > and many more. This also happens in other architectures and configs but
> > (obviously) not all builds.
> >
> > Presumably caused by commit 053361e1a072 ("mm: replace NUMA_BUILD with
> > IS_ENABLED(CONFIG_NUMA)").
>
> I have removed that patch from the akpm tree until a solution is worked out.
>
> Everything seemed to rebase ok with out it and I can't see much actually
> depending on it.
yup, I've removed it from the for-next sections and will probably drop
it altogether.
Hi,
On Sun, Feb 19, 2012 at 1:12 PM, Randy Dunlap <[email protected]> wrote:
> On 02/19/2012 09:01 AM, Geert Uytterhoeven wrote:
>>
>> On Fri, Feb 17, 2012 at 21:30, Andrew Morton<[email protected]>
>> ?wrote:
>>>
>>> On Fri, 17 Feb 2012 16:08:15 +0400
>>> Konstantin Khlebnikov<[email protected]> ?wrote:
>>>
>>>> Config NUMA must be defined for all architectures,
>>>> otherwise IS_ENABLED(CONFIG_NUMA) does not work.
>>>> Some arch-specific Kconfig already has this stub.
>>>> This patch adds it to all remaining.
>>>
>>>
>>> It would be better to teach IS_ENABLED() to handle this situation. ?I
>>> don't think there's a way of doing this with cpp :(
>>>
>>> This limitation makes IS_ENABLED pretty dangerous, doesn't it? ?It
>>> makes it very easy to introduce build breakage with unexpected Kconfig
>>> combinations.
>>
>>
>> Indeed. Recently I discovered IS_ENABLED() and started recommending it
>> to people for new code. But now I've seen the CONFIG_NUMA breakage,
>> I no longer think this is a good recommendation.
>
> adding Michal & linux-kbuild to cc: list.
>
I do not really see any way to fix this, beside having a unique
architecture-wide configuration namespace :/
- Arnaud
On 20.2.2012 00:21, Arnaud Lacombe wrote:
> On Sun, Feb 19, 2012 at 1:12 PM, Randy Dunlap <[email protected]> wrote:
>> On 02/19/2012 09:01 AM, Geert Uytterhoeven wrote:
>>>
>>> On Fri, Feb 17, 2012 at 21:30, Andrew Morton<[email protected]>
>>> wrote:
>>>> It would be better to teach IS_ENABLED() to handle this situation. I
>>>> don't think there's a way of doing this with cpp :(
>>>>
>>>> This limitation makes IS_ENABLED pretty dangerous, doesn't it? It
>>>> makes it very easy to introduce build breakage with unexpected Kconfig
>>>> combinations.
>>>
>>>
>>> Indeed. Recently I discovered IS_ENABLED() and started recommending it
>>> to people for new code. But now I've seen the CONFIG_NUMA breakage,
>>> I no longer think this is a good recommendation.
>>
>> adding Michal & linux-kbuild to cc: list.
>>
> I do not really see any way to fix this, beside having a unique
> architecture-wide configuration namespace :/
Having a single namespace, or less ambitiously, having less
arch-specific config symbol definitions, would be a plus. IS_ENABLED
requiring the symbol to be defined is not bad per se, it prevents typos.
Michal