[RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Sam Ravnborg]

We have many places in the kernel that looks like
the following:

#ifdef CONFIG_FOO
	...
#endif

Which has the disadvantage that the code denoted '...'
are not even built if CONFIG_FOO is not selected in
the current configuration.

We know that gcc do simple code-elimination for
conditionals which is always true/false and
thus the above code could be turned into:

	if (CONFIG_FOO)
		...

One line smaller and we follow the normal flow in the program.
The code is always build but we do not waste space as gcc will
do proper code-elimination for us.

Today this is not possible because kconfig will only
define CONFIG_FOO if selected and FOO is not a module.

The following patch implement a new set of defines in
the KCONFIG_* namespace.

For a tristate symbol the following are defined:

FOO not selected: 
#define KCONFIG_FOO        0
#define KCONFIG_FOO_MODULE 0

FOO is built-in ('y')
#define KCONFIG_FOO        1
#define KCONFIG_FOO_MODULE 0

FOO is a module ('m'):
#define KCONFIG_FOO        1
#define KCONFIG_FOO_MODULE 1

In other words KCONFIG_FOO will say if the
symbol is selected and KCONFIG_FOO_MODULE
will say if it is a module.

With the above included we can now do:

	if (KCONFIG_FOO)
		...

This is not a replacement for the CONFIG_*
defines but a pleasant supplement.
Using KCONFIG_FOO will also give us a nice
error message the day that FOO is no longer part
of the configuration.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index ee5fe94..011a5ec 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -666,6 +666,31 @@ out:
 	return res;
 }
 
+static void write_tristate(FILE *m, FILE *h, struct symbol *sym)
+{
+	switch (sym_get_tristate_value(sym)) {
+	case mod:
+		fprintf(m, "CONFIG_%s=m\n", sym->name);
+		fprintf(h, "#define CONFIG_%s_MODULE 1\n", sym->name);
+		fprintf(h, "#define KCONFIG_%s 1\n", sym->name);
+		if (sym->type == S_TRISTATE)
+			fprintf(h, "#define KCONFIG_%s_MODULE 1\n", sym->name);
+		break;
+	case yes:
+		fprintf(m, "CONFIG_%s=y\n", sym->name);
+		fprintf(h, "#define CONFIG_%s 1\n", sym->name);
+		fprintf(h, "#define KCONFIG_%s 1\n", sym->name);
+		if (sym->type == S_TRISTATE)
+			fprintf(h, "#define KCONFIG_%s_MODULE 0\n", sym->name);
+		break;
+	case no:
+		fprintf(h, "#define KCONFIG_%s 0\n", sym->name);
+		if (sym->type == S_TRISTATE)
+			fprintf(h, "#define KCONFIG_%s_MODULE 0\n", sym->name);
+		break;
+	}
+}
+
 int conf_write_autoconf(void)
 {
 	struct symbol *sym;
@@ -716,18 +741,7 @@ int conf_write_autoconf(void)
 		switch (sym->type) {
 		case S_BOOLEAN:
 		case S_TRISTATE:
-			switch (sym_get_tristate_value(sym)) {
-			case no:
-				break;
-			case mod:
-				fprintf(out, "CONFIG_%s=m\n", sym->name);
-				fprintf(out_h, "#define CONFIG_%s_MODULE 1\n", sym->name);
-				break;
-			case yes:
-				fprintf(out, "CONFIG_%s=y\n", sym->name);
-				fprintf(out_h, "#define CONFIG_%s 1\n", sym->name);
-				break;
-			}
+			write_tristate(out, out_h, sym);
 			break;
 		case S_STRING:
 			str = sym_get_string_value(sym);

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Andrew Morton]

On Sat, 24 May 2008 21:25:40 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:

> We have many places in the kernel that looks like
> the following:
> 
> #ifdef CONFIG_FOO
> 	...
> #endif
> 
> Which has the disadvantage that the code denoted '...'
> are not even built if CONFIG_FOO is not selected in
> the current configuration.
> 
> We know that gcc do simple code-elimination for
> conditionals which is always true/false and
> thus the above code could be turned into:
> 
> 	if (CONFIG_FOO)
> 		...
> 
> One line smaller and we follow the normal flow in the program.
> The code is always build but we do not waste space as gcc will
> do proper code-elimination for us.
> 
> Today this is not possible because kconfig will only
> define CONFIG_FOO if selected and FOO is not a module.
> 
> The following patch implement a new set of defines in
> the KCONFIG_* namespace.
> 
> For a tristate symbol the following are defined:
> 
> FOO not selected: 
> #define KCONFIG_FOO        0
> #define KCONFIG_FOO_MODULE 0
> 
> FOO is built-in ('y')
> #define KCONFIG_FOO        1
> #define KCONFIG_FOO_MODULE 0
> 
> FOO is a module ('m'):
> #define KCONFIG_FOO        1
> #define KCONFIG_FOO_MODULE 1
> 
> In other words KCONFIG_FOO will say if the
> symbol is selected and KCONFIG_FOO_MODULE
> will say if it is a module.
> 
> With the above included we can now do:
> 
> 	if (KCONFIG_FOO)
> 		...
> 
> This is not a replacement for the CONFIG_*
> defines but a pleasant supplement.
> Using KCONFIG_FOO will also give us a nice
> error message the day that FOO is no longer part
> of the configuration.

It could help to get us out of the occasional sticky situation, but it
does seem a bit risky.  What happens with Kconfig variables which are
just not known about at all with some .configs?

Silly example, one could add

	if (KCONFIG_DVB_VES1820)

to kernel/sched.c and that would work happily until someone sets DVB=n,
in which case I assume KCONFIG_DVB_VES1820 doesn't get defined
anywhere?

A more realistic example might be using an x86-only KCONFIG_* in non-x86
code.

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Jeremy Fitzhardinge]

Andrew Morton wrote:
> It could help to get us out of the occasional sticky situation, but it
>   

I think if you know you can use the if(KCONFIG_) technique, then one 
would tend to structure things so that you do it as much as possible.  
Ideally you'd use CONFIG vars in Makefiles to make code go away 
entirely, and if (KCONFIG_) in .c files to do conditional compilation.

> does seem a bit risky.  What happens with Kconfig variables which are
> just not known about at all with some .configs?
>
> Silly example, one could add
>
> 	if (KCONFIG_DVB_VES1820)
>
> to kernel/sched.c and that would work happily until someone sets DVB=n,
> in which case I assume KCONFIG_DVB_VES1820 doesn't get defined
> anywhere?
>
> A more realistic example might be using an x86-only KCONFIG_* in non-x86
> code.
>   

Well, logically that means that all config vars are always "known", even 
if they can never be defined.  I don't know what the practicalities of 
that are: can all Kconfig files everywhere reasonably be scanned to 
produce the symbol list?

    J

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Sam Ravnborg]

On Sat, May 24, 2008 at 09:14:46PM +0100, Jeremy Fitzhardinge wrote:
> Andrew Morton wrote:
> >It could help to get us out of the occasional sticky situation, but it
> >  
> 
> I think if you know you can use the if(KCONFIG_) technique, then one 
> would tend to structure things so that you do it as much as possible.  
> Ideally you'd use CONFIG vars in Makefiles to make code go away 
> entirely, and if (KCONFIG_) in .c files to do conditional compilation.
> 
> >does seem a bit risky.  What happens with Kconfig variables which are
> >just not known about at all with some .configs?
> >
> >Silly example, one could add
> >
> >	if (KCONFIG_DVB_VES1820)
> >
> >to kernel/sched.c and that would work happily until someone sets DVB=n,
> >in which case I assume KCONFIG_DVB_VES1820 doesn't get defined
> >anywhere?
> >
> >A more realistic example might be using an x86-only KCONFIG_* in non-x86
> >code.
> >  
> 
> Well, logically that means that all config vars are always "known", even 
> if they can never be defined.  I don't know what the practicalities of 
> that are: can all Kconfig files everywhere reasonably be scanned to 
> produce the symbol list?

When we have one configuration for the kernel and not as today
where we have one configuration for each architecture (with a lot
of shared files) then it is already taken care of by my (updated) patch.

	Sam

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Jeremy Fitzhardinge]

Sam Ravnborg wrote:
> When we have one configuration for the kernel and not as today
> where we have one configuration for each architecture (with a lot
> of shared files) then it is already taken care of by my (updated) patch.

Yep.  But is a unified config something that someone is actively working 
on, or a distant pipe dream?

    J

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Sam Ravnborg]

On Sat, May 24, 2008 at 09:56:50PM +0100, Jeremy Fitzhardinge wrote:
> Sam Ravnborg wrote:
> >When we have one configuration for the kernel and not as today
> >where we have one configuration for each architecture (with a lot
> >of shared files) then it is already taken care of by my (updated) patch.
> 
> Yep.  But is a unified config something that someone is actively working 
> on, or a distant pipe dream?

Midway...
Roman implmented named choices and I have yet to try it out.

But I have a bit on my TODO list before I get there and
limited time (My day-time job is not Linux related).

	Sam

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Sam Ravnborg]

On Sat, May 24, 2008 at 12:53:16PM -0700, Andrew Morton wrote:
> On Sat, 24 May 2008 21:25:40 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > We have many places in the kernel that looks like
> > the following:
> > 
> > #ifdef CONFIG_FOO
> > 	...
> > #endif
> > 
> > Which has the disadvantage that the code denoted '...'
> > are not even built if CONFIG_FOO is not selected in
> > the current configuration.
> > 
> > We know that gcc do simple code-elimination for
> > conditionals which is always true/false and
> > thus the above code could be turned into:
> > 
> > 	if (CONFIG_FOO)
> > 		...
> > 
> > One line smaller and we follow the normal flow in the program.
> > The code is always build but we do not waste space as gcc will
> > do proper code-elimination for us.
> > 
> > Today this is not possible because kconfig will only
> > define CONFIG_FOO if selected and FOO is not a module.
> > 
> > The following patch implement a new set of defines in
> > the KCONFIG_* namespace.
> > 
> > For a tristate symbol the following are defined:
> > 
> > FOO not selected: 
> > #define KCONFIG_FOO        0
> > #define KCONFIG_FOO_MODULE 0
> > 
> > FOO is built-in ('y')
> > #define KCONFIG_FOO        1
> > #define KCONFIG_FOO_MODULE 0
> > 
> > FOO is a module ('m'):
> > #define KCONFIG_FOO        1
> > #define KCONFIG_FOO_MODULE 1
> > 
> > In other words KCONFIG_FOO will say if the
> > symbol is selected and KCONFIG_FOO_MODULE
> > will say if it is a module.
> > 
> > With the above included we can now do:
> > 
> > 	if (KCONFIG_FOO)
> > 		...
> > 
> > This is not a replacement for the CONFIG_*
> > defines but a pleasant supplement.
> > Using KCONFIG_FOO will also give us a nice
> > error message the day that FOO is no longer part
> > of the configuration.
> 
> It could help to get us out of the occasional sticky situation, but it
> does seem a bit risky.  What happens with Kconfig variables which are
> just not known about at all with some .configs?
> 
> Silly example, one could add
> 
> 	if (KCONFIG_DVB_VES1820)
> 
> to kernel/sched.c and that would work happily until someone sets DVB=n,
> in which case I assume KCONFIG_DVB_VES1820 doesn't get defined
> anywhere?
It would have helped if I had applied the correct patch...
All boolean and tristate symbols in the konfiguration have
their symbols defined as KCONFIG_* no matter their values.
So KCONFIG_DVB_VES1820 would get defined.

Correct patch below.

	Sam

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index ee5fe94..247ea30 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -666,6 +666,43 @@ out:
 	return res;
 }
 
+static void write_tristate_config(FILE *m, FILE *h, struct symbol *sym)
+{
+	switch (sym_get_tristate_value(sym)) {
+	case mod:
+		fprintf(m, "CONFIG_%s=m\n", sym->name);
+		fprintf(h, "#define CONFIG_%s_MODULE 1\n", sym->name);
+		break;
+	case yes:
+		fprintf(m, "CONFIG_%s=y\n", sym->name);
+		fprintf(h, "#define CONFIG_%s 1\n", sym->name);
+		break;
+	case no:
+		break;
+	}
+}
+
+static void write_tristate_kconfig(FILE *f, struct symbol *sym)
+{
+	switch (sym_get_tristate_value(sym)) {
+	case mod:
+		fprintf(f, "#define KCONFIG_%s 1\n", sym->name);
+		if (sym->type == S_TRISTATE)
+			fprintf(f, "#define KCONFIG_%s_MODULE 1\n", sym->name);
+		break;
+	case yes:
+		fprintf(f, "#define KCONFIG_%s 1\n", sym->name);
+		if (sym->type == S_TRISTATE)
+			fprintf(f, "#define KCONFIG_%s_MODULE 0\n", sym->name);
+		break;
+	case no:
+		fprintf(f, "#define KCONFIG_%s 0\n", sym->name);
+		if (sym->type == S_TRISTATE)
+			fprintf(f, "#define KCONFIG_%s_MODULE 0\n", sym->name);
+		break;
+	}
+}
+
 int conf_write_autoconf(void)
 {
 	struct symbol *sym;
@@ -716,18 +753,7 @@ int conf_write_autoconf(void)
 		switch (sym->type) {
 		case S_BOOLEAN:
 		case S_TRISTATE:
-			switch (sym_get_tristate_value(sym)) {
-			case no:
-				break;
-			case mod:
-				fprintf(out, "CONFIG_%s=m\n", sym->name);
-				fprintf(out_h, "#define CONFIG_%s_MODULE 1\n", sym->name);
-				break;
-			case yes:
-				fprintf(out, "CONFIG_%s=y\n", sym->name);
-				fprintf(out_h, "#define CONFIG_%s 1\n", sym->name);
-				break;
-			}
+			write_tristate_config(out, out_h, sym);
 			break;
 		case S_STRING:
 			str = sym_get_string_value(sym);
@@ -765,6 +791,19 @@ int conf_write_autoconf(void)
 			break;
 		}
 	}
+	for_all_symbols(i, sym) {
+		sym_calc_value(sym);
+		if (!sym->name)
+			continue;
+		switch (sym->type) {
+		case S_BOOLEAN:
+		case S_TRISTATE:
+			write_tristate_kconfig(out_h, sym);
+			break;
+		default:
+			break;
+		}
+	}
 	fclose(out);
 	fclose(out_h);
 

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Andrew Morton]

On Sat, 24 May 2008 22:24:27 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:

> > It could help to get us out of the occasional sticky situation, but it
> > does seem a bit risky.  What happens with Kconfig variables which are
> > just not known about at all with some .configs?
> > 
> > Silly example, one could add
> > 
> > 	if (KCONFIG_DVB_VES1820)
> > 
> > to kernel/sched.c and that would work happily until someone sets DVB=n,
> > in which case I assume KCONFIG_DVB_VES1820 doesn't get defined
> > anywhere?
> It would have helped if I had applied the correct patch...
> All boolean and tristate symbols in the konfiguration have
> their symbols defined as KCONFIG_* no matter their values.
> So KCONFIG_DVB_VES1820 would get defined.

But there are still holes - KCONFIG_ARCH_FOOTBRIDGE wouldn't be defined
on x86, for example.  Anything which is inside an `if' or inside an
if/source/endif will not be known about?  I assume?

It's all probably not a big problem in practice - we'd need to be
more-than-usually-silly to trip over things like this.

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Sam Ravnborg]

On Sat, May 24, 2008 at 01:48:15PM -0700, Andrew Morton wrote:
> On Sat, 24 May 2008 22:24:27 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > > It could help to get us out of the occasional sticky situation, but it
> > > does seem a bit risky.  What happens with Kconfig variables which are
> > > just not known about at all with some .configs?
> > > 
> > > Silly example, one could add
> > > 
> > > 	if (KCONFIG_DVB_VES1820)
> > > 
> > > to kernel/sched.c and that would work happily until someone sets DVB=n,
> > > in which case I assume KCONFIG_DVB_VES1820 doesn't get defined
> > > anywhere?
> > It would have helped if I had applied the correct patch...
> > All boolean and tristate symbols in the konfiguration have
> > their symbols defined as KCONFIG_* no matter their values.
> > So KCONFIG_DVB_VES1820 would get defined.
> 
> But there are still holes - KCONFIG_ARCH_FOOTBRIDGE wouldn't be defined
> on x86, for example.
Not today where we have one configuration definition per architecture.

I hope we one day can change that so we have one for the whole
kernel.
This would for example allow us to detect when someone do
a misspelled "depends on FOOBAR" because it will no longer be
a normal situation to depend on unknow symbols.


> Anything which is inside an `if' or inside an
> if/source/endif will not be known about?  I assume?
These symbols would be know of - their value would just be 0.
The correct patch (last one posted) does this.

	Sam

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Adrian Bunk]

On Sat, May 24, 2008 at 09:25:40PM +0200, Sam Ravnborg wrote:
> We have many places in the kernel that looks like
> the following:
> 
> #ifdef CONFIG_FOO
> 	...
> #endif
> 
> Which has the disadvantage that the code denoted '...'
> are not even built if CONFIG_FOO is not selected in
> the current configuration.
> 
> We know that gcc do simple code-elimination for
> conditionals which is always true/false and
> thus the above code could be turned into:
> 
> 	if (CONFIG_FOO)
> 		...
> 
> One line smaller and we follow the normal flow in the program.
> The code is always build but we do not waste space as gcc will
> do proper code-elimination for us.
> 
> Today this is not possible because kconfig will only
> define CONFIG_FOO if selected and FOO is not a module.
> 
> The following patch implement a new set of defines in
> the KCONFIG_* namespace.
> 
> For a tristate symbol the following are defined:
> 
> FOO not selected: 
> #define KCONFIG_FOO        0
> #define KCONFIG_FOO_MODULE 0
> 
> FOO is built-in ('y')
> #define KCONFIG_FOO        1
> #define KCONFIG_FOO_MODULE 0
> 
> FOO is a module ('m'):
> #define KCONFIG_FOO        1
> #define KCONFIG_FOO_MODULE 1
> 
> In other words KCONFIG_FOO will say if the
> symbol is selected and KCONFIG_FOO_MODULE
> will say if it is a module.

If you really want to be able to transform all #if's in .c files to 
if()'s you also have to offer a variant of our MODULE #define.

> With the above included we can now do:
> 
> 	if (KCONFIG_FOO)
> 		...
> 
> This is not a replacement for the CONFIG_*
> defines but a pleasant supplement.
> Using KCONFIG_FOO will also give us a nice
> error message the day that FOO is no longer part
> of the configuration.
>...

Also an error message if if the varible is not currently available on 
this architecture (e.g. KCONFIG_ISA on ia64).

Not an unsolvable problem, but something that has to be taken care of.

cu
Adrian

-- 

       "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

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Sam Ravnborg]

> 
> If you really want to be able to transform all #if's in .c files to 
> if()'s you also have to offer a variant of our MODULE #define.
1) I have no pland to replace the current CONFIG_ use.
2) I do not follow whay you try to say about our "MODULE #define"

> >...
> 
> Also an error message if if the varible is not currently available on 
> this architecture (e.g. KCONFIG_ISA on ia64).
> 
> Not an unsolvable problem, but something that has to be taken care of.

My master plan is to have a single configuration for the kernel
and not as today where we have one configuration for each architecture.

How far away we are from that I dunno. It is a while I visited this.
And I will not have time to do so anytime soon I'm afraid.

	Sam

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Adrian Bunk]

On Sat, May 24, 2008 at 10:44:38PM +0200, Sam Ravnborg wrote:
> > 
> > If you really want to be able to transform all #if's in .c files to 
> > if()'s you also have to offer a variant of our MODULE #define.
> 1) I have no pland to replace the current CONFIG_ use.
> 2) I do not follow whay you try to say about our "MODULE #define"
>...

I'm talking about the one set with
  MODFLAGS        = -DMODULE

But looking through the kernel I have to take my statement back since 
there don't seem to be many usages that could (if wanted) be transformed 
to if()'s at all (and similarily there wouldn't be many use cases in 
the future).

> 	Sam

cu
Adrian

-- 

       "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

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Linus Torvalds]

Can we get the /etc/kernel-config regression fixed before even posting 
things like this? Please?

		Linus

[PATCH] x86: use defconfig as last resort

[Sam Ravnborg]

From: Sam Ravnborg <sam@ravnborg.org>
Subject: [PATCH] x86: use defconfig as last resort

When using "make oldconfig" with no .config
present try the list from init/Kconfig DEFCONFIG_LIST
before resorting to use one of the defconfigs.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---

I had the patch in my local tree but never got it posted.
And then I forgot.

I plan to redo this stuff soonish so we have a more
clean and predictive approach.
But the KCONFIG_ stuff was just more fun ;^)

	Sam

 arch/x86/Kconfig |   24 ++++++++++++------------
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fe361ae..393a169 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -26,18 +26,6 @@ config X86
 	select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
 	select HAVE_ARCH_KGDB if !X86_VOYAGER
 
-config DEFCONFIG_LIST
-	string
-	depends on X86_32
-	option defconfig_list
-	default "arch/x86/configs/i386_defconfig"
-
-config DEFCONFIG_LIST
-	string
-	depends on X86_64
-	option defconfig_list
-	default "arch/x86/configs/x86_64_defconfig"
-
 
 config GENERIC_LOCKBREAK
 	def_bool n
@@ -205,6 +193,18 @@ config KTIME_SCALAR
 	def_bool X86_32
 source "init/Kconfig"
 
+config DEFCONFIG_LIST
+	string
+	depends on X86_32
+	option defconfig_list
+	default "arch/x86/configs/i386_defconfig"
+
+config DEFCONFIG_LIST
+	string
+	depends on X86_64
+	option defconfig_list
+	default "arch/x86/configs/x86_64_defconfig"
+
 menu "Processor type and features"
 
 source "kernel/time/Kconfig"
-- 
1.5.4.1.143.ge7e51

Re: [PATCH] x86: use defconfig as last resort

[Linus Torvalds]

On Sat, 24 May 2008, Sam Ravnborg wrote:
> 
> When using "make oldconfig" with no .config
> present try the list from init/Kconfig DEFCONFIG_LIST
> before resorting to use one of the defconfigs.

Hmm. Why does placement matter here?

Also:

> +config DEFCONFIG_LIST
> +	string
> +	depends on X86_32
> +	option defconfig_list
> +	default "arch/x86/configs/i386_defconfig"
> +
> +config DEFCONFIG_LIST
> +	string
> +	depends on X86_64
> +	option defconfig_list
> +	default "arch/x86/configs/x86_64_defconfig"
> +

Wouldn't this be cleaner as just *one* entry, and then just have 
different default statements, ie something like

    config DEFCONFIG_LIST
	string
	option defconfig_list
	default "arch/x86/configs/i386_defconfig" if X86_32
	default "arch/x86/configs/x86_64_defconfig" if X86_64

instead?

		Linus

Re: [PATCH] x86: use defconfig as last resort

[Sam Ravnborg]

On Sat, May 24, 2008 at 06:30:40PM -0700, Linus Torvalds wrote:
> 
> 
> On Sat, 24 May 2008, Sam Ravnborg wrote:
> > 
> > When using "make oldconfig" with no .config
> > present try the list from init/Kconfig DEFCONFIG_LIST
> > before resorting to use one of the defconfigs.
> 
> Hmm. Why does placement matter here?

We have the following list in init/Kconfig:

config DEFCONFIG_LIST
        string
        depends on !UML
        option defconfig_list
        default "/lib/modules/$UNAME_RELEASE/.config"
        default "/etc/kernel-config"
        default "/boot/config-$UNAME_RELEASE"
        default "arch/$ARCH/defconfig"

If we define an arch specific DEFCONFIG_LIST before this then
the arch supplied values are tried first.
The patch moves the ARCH supplied list below the definition
in init/Kconfig so it is tried last.

> 
> Also:
> 
> > +config DEFCONFIG_LIST
> > +	string
> > +	depends on X86_32
> > +	option defconfig_list
> > +	default "arch/x86/configs/i386_defconfig"
> > +
> > +config DEFCONFIG_LIST
> > +	string
> > +	depends on X86_64
> > +	option defconfig_list
> > +	default "arch/x86/configs/x86_64_defconfig"
> > +
> 
> Wouldn't this be cleaner as just *one* entry, and then just have 
> different default statements, ie something like

I will try to come up with an alternative solution in a minute.

	Sam

Re: [PATCH] x86: use defconfig as last resort

[Sam Ravnborg]

> 
> Wouldn't this be cleaner as just *one* entry, and then just have 
> different default statements, ie something like
> 
>     config DEFCONFIG_LIST
> 	string
> 	option defconfig_list
> 	default "arch/x86/configs/i386_defconfig" if X86_32
> 	default "arch/x86/configs/x86_64_defconfig" if X86_64
> 
> instead?

Following patch moves the stuff away from the arch
specific Kconfig file and works at least for
x86 and alpha.
It uses the already defined environment variables to locate
the defconfig and try known locations.

	Sam

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fe361ae..6a4b98e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -26,19 +26,6 @@ config X86
 	select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
 	select HAVE_ARCH_KGDB if !X86_VOYAGER
 
-config DEFCONFIG_LIST
-	string
-	depends on X86_32
-	option defconfig_list
-	default "arch/x86/configs/i386_defconfig"
-
-config DEFCONFIG_LIST
-	string
-	depends on X86_64
-	option defconfig_list
-	default "arch/x86/configs/x86_64_defconfig"
-
-
 config GENERIC_LOCKBREAK
 	def_bool n
 
diff --git a/init/Kconfig b/init/Kconfig
index 6135d07..2aa7180 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -6,6 +6,14 @@ config KERNELVERSION
 	string
 	option env="KERNELVERSION"
 
+config KBUILD_DEFCONFIG
+	string
+	option env="KBUILD_DEFCONFIG"
+
+config SRCARCH
+	string
+	option env="SRCARCH"
+
 config DEFCONFIG_LIST
 	string
 	depends on !UML
@@ -13,7 +21,8 @@ config DEFCONFIG_LIST
 	default "/lib/modules/$UNAME_RELEASE/.config"
 	default "/etc/kernel-config"
 	default "/boot/config-$UNAME_RELEASE"
-	default "arch/$ARCH/defconfig"
+	default "arch/$SRCARCH/configs/$KBUILD_DEFCONFIG"
+	default "arch/$SRCARCH/defconfig"
 
 menu "General setup"
 

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Jeremy Fitzhardinge]

Sam Ravnborg wrote:
> We have many places in the kernel that looks like
> the following:
>
> #ifdef CONFIG_FOO
> 	...
> #endif
>
> Which has the disadvantage that the code denoted '...'
> are not even built if CONFIG_FOO is not selected in
> the current configuration.
>
> We know that gcc do simple code-elimination for
> conditionals which is always true/false and
> thus the above code could be turned into:
>
> 	if (CONFIG_FOO)
> 		...
>
> One line smaller and we follow the normal flow in the program.
> The code is always build but we do not waste space as gcc will
> do proper code-elimination for us.
>
> Today this is not possible because kconfig will only
> define CONFIG_FOO if selected and FOO is not a module.
>
> The following patch implement a new set of defines in
> the KCONFIG_* namespace.
>
> For a tristate symbol the following are defined:
>
> FOO not selected: 
> #define KCONFIG_FOO        0
> #define KCONFIG_FOO_MODULE 0
>
> FOO is built-in ('y')
> #define KCONFIG_FOO        1
> #define KCONFIG_FOO_MODULE 0
>
> FOO is a module ('m'):
> #define KCONFIG_FOO        1
> #define KCONFIG_FOO_MODULE 1
>
> In other words KCONFIG_FOO will say if the
> symbol is selected and KCONFIG_FOO_MODULE
> will say if it is a module.
>
> With the above included we can now do:
>
> 	if (KCONFIG_FOO)
> 		...
>
> This is not a replacement for the CONFIG_*
> defines but a pleasant supplement.
> Using KCONFIG_FOO will also give us a nice
> error message the day that FOO is no longer part
> of the configuration.
>   

How about rather than defining a pile of new constants, we just define:

#define KCONFIG(x)   (x - 0)      /* XXX choose better macro name */

That would allow CONFIG_X variables to be used in C expressions, while 
still coping with non-existent/unknown CONFIG vars.  Also saves on a lot 
of #defines...

    J

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Jeremy Fitzhardinge]

Jeremy Fitzhardinge wrote:
> Sam Ravnborg wrote:
>> We have many places in the kernel that looks like
>> the following:
>>
>> #ifdef CONFIG_FOO
>>     ...
>> #endif
>>
>> Which has the disadvantage that the code denoted '...'
>> are not even built if CONFIG_FOO is not selected in
>> the current configuration.
>>
>> We know that gcc do simple code-elimination for
>> conditionals which is always true/false and
>> thus the above code could be turned into:
>>
>>     if (CONFIG_FOO)
>>         ...
>>
>> One line smaller and we follow the normal flow in the program.
>> The code is always build but we do not waste space as gcc will
>> do proper code-elimination for us.
>>
>> Today this is not possible because kconfig will only
>> define CONFIG_FOO if selected and FOO is not a module.
>>
>> The following patch implement a new set of defines in
>> the KCONFIG_* namespace.
>>
>> For a tristate symbol the following are defined:
>>
>> FOO not selected: #define KCONFIG_FOO        0
>> #define KCONFIG_FOO_MODULE 0
>>
>> FOO is built-in ('y')
>> #define KCONFIG_FOO        1
>> #define KCONFIG_FOO_MODULE 0
>>
>> FOO is a module ('m'):
>> #define KCONFIG_FOO        1
>> #define KCONFIG_FOO_MODULE 1
>>
>> In other words KCONFIG_FOO will say if the
>> symbol is selected and KCONFIG_FOO_MODULE
>> will say if it is a module.
>>
>> With the above included we can now do:
>>
>>     if (KCONFIG_FOO)
>>         ...
>>
>> This is not a replacement for the CONFIG_*
>> defines but a pleasant supplement.
>> Using KCONFIG_FOO will also give us a nice
>> error message the day that FOO is no longer part
>> of the configuration.
>>   
>
> How about rather than defining a pile of new constants, we just define:
>
> #define KCONFIG(x)   (x - 0)      /* XXX choose better macro name */

Would

    #define KCONFIG(x)   (CONFIG_##x - 0)

    if (KCONFIG(PREEMPT)) {
        ...
    }

work?

    J

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Adrian Bunk]

On Sat, May 24, 2008 at 09:58:47PM +0100, Jeremy Fitzhardinge wrote:
> 
> Would
>
>    #define KCONFIG(x)   (CONFIG_##x - 0)
>
>    if (KCONFIG(PREEMPT)) {
>        ...
>    }
>
> work?

$ cat test.c
#define KCONFIG(x)   (CONFIG_##x - 0)

int main()
{
  if (KCONFIG(PREEMPT))
    ;

  return 0;
}
$ gcc -O2 -Wall test.c
test.c: In function ‘main’:
test.c:5: error: ‘CONFIG_PREEMPT’ undeclared (first use in this function)
test.c:5: error: (Each undeclared identifier is reported only once
test.c:5: error: for each function it appears in.)
$ gcc --version
gcc (Debian 4.3.0-5) 4.3.1 20080523 (prerelease)

>    J

cu
Adrian

-- 

       "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

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Jeremy Fitzhardinge]

Adrian Bunk wrote:
> On Sat, May 24, 2008 at 09:58:47PM +0100, Jeremy Fitzhardinge wrote:
>   
>> Would
>>
>>    #define KCONFIG(x)   (CONFIG_##x - 0)
>>
>>    if (KCONFIG(PREEMPT)) {
>>        ...
>>    }
>>
>> work?
>>     
>
> $ cat test.c
> #define KCONFIG(x)   (CONFIG_##x - 0)
>
> int main()
> {
>   if (KCONFIG(PREEMPT))
>     ;
>
>   return 0;
> }
> $ gcc -O2 -Wall test.c
> test.c: In function ‘main’:
> test.c:5: error: ‘CONFIG_PREEMPT’ undeclared (first use in this function)
> test.c:5: error: (Each undeclared identifier is reported only once
> test.c:5: error: for each function it appears in.)
>   

You and your scientific method.

Yeah, this is one of those cases where you need cpp to rescan its input 
after pasting, and I don't think it will ever do that.

    J

Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files

[Pavel Machek]

Hi!

> One line smaller and we follow the normal flow in the program.
> The code is always build but we do not waste space as gcc will
> do proper code-elimination for us.
> 
> Today this is not possible because kconfig will only
> define CONFIG_FOO if selected and FOO is not a module.
> 
> The following patch implement a new set of defines in
> the KCONFIG_* namespace.

Could we s/KCONFIG_/CFG_/g ?

CONFIG_ is long enough already, and K there is very maningless.....


							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html