kconfig: introduce KCONFIG_* symbols for .c files

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.

Quoted 2 lines · Andrew Morton

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.

Quoted 11 lines

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?

Quoted 3 lines

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.

Quoted 3 lines · Sam Ravnborg

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?

Quoted 48 lines · On Sat, 24 May 2008 21:25:40 +0200 Sam Ravnborg <[email protected]> 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:

Quoted 8 lines

	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?

Quoted 8 lines

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)

Quoted 3 lines

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.

Quoted 11 lines · On Sat, 24 May 2008 22:24:27 +0200 Sam Ravnborg <[email protected]> wrote:

Quoted 11 lines

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?

Quoted 4 lines

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?

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.
...

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.

Quoted 1 line

...

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.

Quoted 3 lines

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"
...

Sam

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

Quoted 4 lines · Sam Ravnborg

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:

arch/x86/Kconfig config KTIME_SCALAR · line 207

Quoted 12 lines

arch/x86/Kconfig +12 -0

+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

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?

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.

Quoted 47 lines · 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:

Quoted 9 lines

    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

Quoted 10 lines · Jeremy Fitzhardinge

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.)

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.