linux-kernel - Re: [PATCH] kconfig: Only generate config_is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 Jul 2011 15:45:39 +0200
From:	Michal Marek <mmarek@...e.cz>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Arnaud Lacombe <lacombar@...il.com>, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Valdis.Kletnieks@...edu
Subject: Re: [PATCH] kconfig: Only generate config_is_xxx for bool and tristate
 options

On 13.7.2011 22:08, Sam Ravnborg wrote:
> On Wed, Jul 13, 2011 at 03:22:45PM +0200, Michal Marek wrote:
>> On 18.5.2011 08:23, Arnaud Lacombe wrote:
>>> 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:
>
> But then we clutter the namesapce with another set of variables that will
> be misued. If not in the kernel then by other kconfig users.

Well, no sane person will prefix their variables with 
"__enabled_CONFIG_", so I'm not so worried about the namespace pollution.


> Arnaud approach is nice as it does not require any additional
> symbols to be generated.

Sure, I would also prefer a solution without that doesn't require 
generating new macros. But your's and Arnaud's trick doesn't eliminate 
the configured-out code at -O0, while with the help of the generated 
helper macros, the compiler sees an if(0) or if(1).


> +#include<linux/compiler.h>
> +
> +#define __symbol_value(sym)       __ ## x
> +#define __symbol_module(sym)      __symbol_value(__ ## sym ## _MODULE)
> +
> +/* return 1 if x is defined and not a module */
> +#define KCONFIG_NON_MODULE(sym)					\
> +	({ int __1 __maybe_unused = 1;				\
> +	   int __ ## sym __maybe_unused = 0;			\
> +	   __symbol_value(sym); })
> +
> +/* return 1 if sym is a module symbol */
> +#define KCONFIG_MODULE(sym)					\
> +	({ int __1 __maybe_unused = 1;				\
> +	   int __ ## sym ## _MODULE __maybe_unused = 0;	\
> +	   __symbol_value(sym); })
> +
> +/* return 1 if sym is defined - module or not */
> +#define KCONFIG(sym) (KCONFIG_NON_MODULE(sym) || KCONFIG_MODULE(sym))

With this extra expansion, the passed CONFIG_FOO expands to 1 here and 
the KCONFIG(_NON)_MODULE macros will then only see the 1 and fail.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/