public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Marek <mmarek@suse.cz>
To: Arnaud Lacombe <lacombar@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	Valdis.Kletnieks@vt.edu
Subject: Re: [PATCH] kconfig: Only generate config_is_xxx for bool and tristate options
Date: Wed, 13 Jul 2011 15:22:45 +0200	[thread overview]
Message-ID: <4E1D9C25.8080300@suse.cz> (raw)
In-Reply-To: <BANLkTikmO7D3kUgU62d4_VC2ZPZCnSEqKA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2538 bytes --]

On 18.5.2011 08:23, Arnaud Lacombe wrote:
> Hi,
>
> [added Valdis.Kletnieks@vt.edu to CC:]
>
> On Tue, May 17, 2011 at 3:53 PM, Sam Ravnborg<sam@ravnborg.org>  wrote:
>> On Tue, May 17, 2011 at 05:35:32PM +0200, Michal Marek wrote:
>>> For strings and integers, the config_is_xxx macros are useless and
>>> sometimes misleading:
>>>
>>>    #define CONFIG_INITRAMFS_SOURCE ""
>>>    #define config_is_initramfs_source() 1
>>
>> I'm late with this comment....
>> Could we introduce "config_is_foo" using a syntax that
>> does not break grepability?
>>
>> Maybe a syntax like this?
>>
>>     #ifdef CONFIG_FOO
>>
>> and
>>
>>     if (KCONFIG_FOO())
>>
>> Grepping for the use of a symbol is a very typical thing,
>> so we should try to keep this.
>> And with the suggested syntax above I expect fixdep to
>> catch up both usage types.
>>
> Actually, there is already an issue, on a much smaller scale, in the
> current tree with NUMA_BUILD and COMPACTION_BUILD. The real way to fix
> this would be to always defines CONFIG_FOO, its value being 1 or 0
> depending on whether or not the symbol is selected. This is a
> +35k/-35k change.
>
> Also, I find KCONFIG_FOO() is too specific to be in the kernel source,
> and redundant with CONFIG_FOO.
>
> I've been playing a bit with the preprocessor, and reached that point:
>
> #define EXPAND(x)       __ ## x
> #define CONFIGURED(x)   \
>          ({  int __1 __maybe_unused = 1;         \
>              int __ ## x __maybe_unused = 0;     \
>              EXPAND(x); })
>
> I am not specifically proud of that, use case would be:
>
> extern func(void);
> int fn()
> {
>          if(CONFIGURED(CONFIG_FOO))
>                  func();
> }

I finally got round to revisit this. Your approach inspired me to a much 
simpler scheme: Instead of generating the config_is_xxx macros for 
direct use in the code, name them __enabled_CONFIG_XXX or similar and 
have a macro that expands given CONFIG_XXX symbol to the other form:

/*
  * Usage: ENABLED(CONFIG_FOO)
  * Please do not use the __enabled_CONFIG_FOO defines directly to not break
  * grepability of the code.
  */
#define ENABLED(x) __enabled_ ## x

plus a checkpatch.pl check so that people do not use the 
__enabled_CONFIG_FOO macros in their code. git grep -w CONFIG_FOO 
continues to work, fixdep continues to work, it works with -O0 because 
it expands to a if(1) or if(0). Am I missing some obvious problem?

Attached is my test program:
$ gcc -Wall -O0 test.c
$ ./a.out
Foo1.0
Foo1.1
$ strings ./a.out | grep Foo
Foo1.0
Foo1.1

Michal

[-- Attachment #2: test.c --]
[-- Type: text/plain, Size: 520 bytes --]

#include <stdio.h>

#define CONFIG_FOO1 1
#undef CONFIG_FOO2
#define __enabled_CONFIG_FOO1 1
#define __enabled_CONFIG_FOO2 0

/*
 * Usage: ENABLED(CONFIG_FOO)
 * Please do not use the __enabled_CONFIG_FOO defines directly to not break
 * grepability of the code.
 */
#define ENABLED(x) __enabled_ ## x

int main(void)
{
#ifdef CONFIG_FOO1
	puts("Foo1.0");
#endif
#ifdef CONFIG_FOO2
	puts("Foo2.0");
#endif
	if (ENABLED(CONFIG_FOO1)) {
		puts("Foo1.1");
	}
	if (ENABLED(CONFIG_FOO2)) {
		puts("Foo2.1");
	}
	return 0;
}


  reply	other threads:[~2011-07-13 13:22 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-17 15:35 [PATCH] kconfig: Only generate config_is_xxx for bool and tristate options Michal Marek
2011-05-17 18:05 ` Jean-Christophe PLAGNIOL-VILLARD
2011-05-17 19:44   ` Michal Marek
2011-05-17 19:53 ` Sam Ravnborg
2011-05-18  5:16   ` Jean-Christophe PLAGNIOL-VILLARD
2011-05-18  6:19     ` Sam Ravnborg
2011-05-18  6:27       ` Arnaud Lacombe
2011-05-18  6:23   ` Arnaud Lacombe
2011-07-13 13:22     ` Michal Marek [this message]
2011-07-13 15:20       ` Arnaud Lacombe
2011-07-13 20:08       ` Sam Ravnborg
2011-07-19 13:45         ` Michal Marek
2011-07-25 22:58       ` [RFC][PATCH 1/2] kconfig: Introduce KCONFIG(), KCONFIG_BUILTIN() and KCONFIG_MODULE() Michal Marek
2011-07-25 22:58         ` [RFC][PATCH 2/2] mm: Switch NUMA_BUILD and COMPACTION_BUILD to new KCONFIG() syntax Michal Marek
2011-07-26 15:19           ` Michal Hocko
2011-07-26 18:34             ` Michal Marek
2011-07-26 18:52               ` Michal Hocko
2011-07-26 13:01         ` [RFC][PATCH 1/2] kconfig: Introduce KCONFIG(), KCONFIG_BUILTIN() and KCONFIG_MODULE() Américo Wang
2011-07-26 13:21           ` Michal Marek
2011-07-26 15:04             ` Randy Dunlap
2011-07-26 18:28               ` Michal Marek
2011-07-26 18:28                 ` Randy Dunlap
2011-07-26 18:48                   ` Arnaud Lacombe
2011-07-27  0:42                     ` Arnaud Lacombe
2011-07-27  4:35                       ` Randy Dunlap
2011-07-27  8:36                         ` Michal Marek
2011-07-27 13:31                           ` Arnaud Lacombe
2011-07-27 13:38                             ` Michal Marek
2011-07-27 15:11                               ` Arnaud Lacombe
2011-07-27 15:18                                 ` Michal Marek
2011-07-27 16:36                           ` Américo Wang
2011-07-27 15:09         ` Arnaud Lacombe
2011-07-27 15:16           ` Michal Marek
2011-07-27 15:18             ` Arnaud Lacombe
2011-07-29 13:51         ` [PATCH] kconfig: Introduce IS_ENABLED(), IS_BUILTIN() and IS_MODULE() Michal Marek
2011-07-29 17:43           ` Arnaud Lacombe
2011-07-29 18:25           ` Randy Dunlap
2011-07-29 18:58             ` Arnaud Lacombe
2011-08-02 17:33           ` Sam Ravnborg
2011-08-02 17:50             ` Arnaud Lacombe
2011-08-02 19:26               ` Sam Ravnborg
2011-08-02 19:33                 ` Michal Marek
2011-08-02 19:33                   ` Arnaud Lacombe
2011-05-25 13:35 ` [PATCH] kconfig: Only generate config_is_xxx for bool and tristate options Michal Marek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E1D9C25.8080300@suse.cz \
    --to=mmarek@suse.cz \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=lacombar@gmail.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=plagnioj@jcrosoft.com \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox