From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756416AbbJGVdb (ORCPT ); Wed, 7 Oct 2015 17:33:31 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:35400 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754669AbbJGVd3 (ORCPT ); Wed, 7 Oct 2015 17:33:29 -0400 From: Rasmus Villemoes To: Michal Marek Cc: Paul Gortmaker , Jiri Slaby , Ingo Molnar , Andrew Morton , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] linux/kconfig.h: generalize IS_ENABLED logic Organization: D03 References: <5613F3DE.4010406@suse.cz> <1444165543-2209-1-git-send-email-linux@rasmusvillemoes.dk> <5614D49F.8070006@suse.cz> X-Hashcash: 1:20:151007:mingo@redhat.com::Uhd023NiG5uoM2LQ:000j7 X-Hashcash: 1:20:151007:jslaby@suse.cz::2LSQOvLGaj7bPvJZ:0000umS X-Hashcash: 1:20:151007:mmarek@suse.cz::7IK9/L101YNFtdTi:0000+Jn X-Hashcash: 1:20:151007:linux-kernel@vger.kernel.org::sEbqSMEcpHM7MNIc:0000000000000000000000000000000001HMn X-Hashcash: 1:20:151007:tglx@linutronix.de::HM67wrlkzxxnn9x9:00000000000000000000000000000000000000000001aOp X-Hashcash: 1:20:151007:hpa@zytor.com::adHYiB1Jz+VCNyUo:00002XpG X-Hashcash: 1:20:151007:akpm@linux-foundation.org::a3Alj6sr01lCIRpN:00000000000000000000000000000000000034WD X-Hashcash: 1:20:151007:paul.gortmaker@windriver.com::cu8Y0CVlREI0ugfK:0000000000000000000000000000000006BRo Date: Wed, 07 Oct 2015 23:33:25 +0200 In-Reply-To: <5614D49F.8070006@suse.cz> (Michal Marek's message of "Wed, 7 Oct 2015 10:15:27 +0200") Message-ID: <87twq2pdne.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 07 2015, Michal Marek wrote: > On 2015-10-06 23:05, Rasmus Villemoes wrote: >> It's not hard to generalize the macro magic used to build the >> IS_ENABLED macro and friends to produce a few other potentially useful >> macros: >> >> CHOOSE_EXPR(CONFIG_FOO, expr): if CONFIG_FOO is set expands to >> expr, otherwise expands to nothing. >> >> CHOOSE_EXPR(CONFIG_FOO, expr1, expr2): if CONFIG_FOO is set, >> expands to expr1, otherwise expands to expr2. > > FWIW, I agree with Ingo that the CHOOSE_EXPR name is not really obvious. > IF_CONFIG is a better alternative IMO, since the average programmer > probably does not know __builtin_choose_expr() to see the analogy. OK, CHOOSE_EXPR is out. But I think IF_CONFIG/COND_CONFIG might be a little annoying or redundant, since "CONFIG" would also always be part of the first argument. Come to think of it, since this would be a primitive for conditional compilation whose primary purpose is to eliminate the verbosity of #ifdef/#endif, I'd prefer plain and simple COND, with COND_INITIALIZER as a sidekick for that special purpose. Unfortunately, COND is already used in a few places :( So I'll go with COND_CONFIG for now, but wait a few days before sending v2, to see if anyone else has comments or naming suggestions. > While the C standard syntax requires struct-declaration to actually > declare a member, the compiler will happily ignore the extra semicolon > if you write > > truct task_struct { > ... > CHOOSE_EXPR(CONFIG_KASAN, unsigned int kasan_depth); > ... > } > > So I think that the COND_DECLARATION macro is not necessary. Thanks, I didn't know that. I see that both gcc and clang accept it whether the extra semicolon is at the beginning or end of the struct, and whether there's even a single actual member. OK, then COND_DECLARATION is redundant (though it might still be useful as a natural buddy to COND_INITIALIZER). >> #define INIT_KASAN(tsk) COND_INITIALIZER(CONFIG_KASAN, .kasan_depth = 1) > > COND_INITIALIZER on the other hand is useful (CHOOSE_EXPR(CONFIG_KASAN, > .kasan_depth = 1 _COMMA) does does not work, unfortunately). Yeah, since we need to do the multiple expansion thing there's no way of preventing _COMMA from expanding too early, so I'm pretty sure one would need some specialized version of CHOOSE_EXPR (or whatever the name ends up being). Also, I wouldn't really want users to have to supply the _COMMA. One could also consider making COND_ARGUMENT an alias for it - that could be useful for some seq_printf calls generating /proc files (where the format string would be built with COND_CONFIG). >> [and I'm certainly not proposing any mass conversion], but I think it >> might be nice to avoid lots of short #ifdef/#else/#endif sections. > > It should be accompanied by a patch to scripts/tags.sh teaching > ctags/etags about the new macros. Do you mean that something like --regex-c='/COND_CONFIG\([^,]*,([^,]*)\)/\1/' should be added so ctags would pick up the text in the true branch? I'm not very familiar with ctags. Thanks for the feedback, Michal and Ingo. Rasmus