Messages in this thread | | | Date | Wed, 18 May 2011 02:23:26 -0400 | Subject | Re: [PATCH] kconfig: Only generate config_is_xxx for bool and tristate options | From | Arnaud Lacombe <> |
| |
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(); }
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |