Hi,
[added Valdis.Kletnieks@xxxxxx to CC:]
On Tue, May 17, 2011 at 3:53 PM, Sam Ravnborg <sam@xxxxxxxxxxxx> 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();
}
The issue I am seeing is that it adds a dependency to the optimizer,
as gcc will not optimize the branch away at -O0.
The advantage is that it is not intrusive at all within kconfig.
- Arnaud
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
