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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ