[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DC7AB57.9050002@suse.cz>
Date: Mon, 09 May 2011 10:52:39 +0200
From: Michal Marek <mmarek@...e.cz>
To: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
Cc: Arnaud Lacombe <lacombar@...il.com>, linux-kernel@...r.kernel.org,
linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v2] kconfig: autogenerated config_is_xxx macro
On 7.5.2011 03:50, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:19 Fri 06 May , Arnaud Lacombe wrote:
>> Why would it be a good thing ?
>>
>> Most configuration-dependent code inside functions tends to be moved
>> to a static inline already, which get conditionally defined based on
>> the CONFIG_<foo>. If it is not, then the code is badly architectured
>> (-> bad). Using that if(xxx) notation would also lead to yet more
>> heavily indented function (-> bad). Moreover, this introduces
>> yet-another way to check for an information (-> bad), and you will end
>> up with mixing the config_is_<xxx> notation inside a function
>> declaration, and CONFIG_<xxx> when not inside a function (-> bad)
>>
>> Actually, this is even worse than that as you'll not be able to hide
>> structure (or structure members) inside CONFIG_<xxx> and use that
>> structure (or structure members) in config_is_<xxx> protected block
>> without causing compile-time failure.
> sorry but conditionnal structure members is bad practice
> you save nearly no space nut for the test of the code in multiple
> configuration. Use union for this.
>
> the compile-time failure is good here. it's means your code is not generic.
>
> specially when you want to keep code running on multiple soc/arch keep compiling
> no matter the configuration
>
> #ifdef in the code is a really bad habit
Do you have proof of concept patches that make use of the config_is_xxx
macros? Acked by the respective subsystem maintainers? It would be a
good idea to send them along to show that this feature is going to be
actually used.
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/
Powered by blists - more mailing lists