Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752379Ab1EQBOu (ORCPT ); Mon, 16 May 2011 21:14:50 -0400 Received: from 64.mail-out.ovh.net ([91.121.185.65]:33056 "HELO 64.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751484Ab1EQBOt (ORCPT ); Mon, 16 May 2011 21:14:49 -0400 Date: Tue, 17 May 2011 03:03:29 +0200 From: Jean-Christophe PLAGNIOL-VILLARD To: Arnaud Lacombe Cc: Valdis.Kletnieks@vt.edu, Michal Marek , linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, x86@kernel.org, Ingo Molnar Subject: Re: [PATCH v2] kconfig: autogenerated config_is_xxx macro Message-ID: <20110517010329.GB13466@game.jcrosoft.org> References: <1304658229-30820-1-git-send-email-plagnioj@jcrosoft.com> <20110507015041.GA21017@game.jcrosoft.org> <4DC7AB57.9050002@suse.cz> <20110513080909.GO18952@game.jcrosoft.org> <32557.1305572616@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-PGP-Key: http://uboot.jcrosoft.org/plagnioj.asc X-PGP-key-fingerprint: 6309 2BBA 16C8 3A07 1772 CC24 DEFC FFA3 279C CE7C User-Agent: Mutt/1.5.20 (2009-06-14) X-Ovh-Tracer-Id: 14700593609168694265 X-Ovh-Remote: 213.251.161.87 (ns32433.ovh.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2974 Lines: 77 On 15:38 Mon 16 May , Arnaud Lacombe wrote: > Hi, > > On Mon, May 16, 2011 at 3:03 PM, wrote: > > On Fri, 13 May 2011 10:09:09 +0200, Jean-Christophe PLAGNIOL-VILLARD said: > >> On 10:52 Mon 09 May ? ? , Michal Marek wrote: > >> > 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. > >> I've seen thousands of place in the kernel we can use > >> so I'll just take one example on x86 > >> > >> the patch attached is just an example > > > > Out of curiosity, will this Do The Right Thing for cases where things simply won't > > build for some configs? ?For example, consider this code snippet from kernel/timer.c, > > in __mod_timer() (near line 682): > > > > ? ? ? ?debug_activate(timer, expires); > > > > ? ? ? ?cpu = smp_processor_id(); > > > > #if defined(CONFIG_NO_HZ) && defined(CONFIG_SMP) > > ? ? ? ?if (!pinned && get_sysctl_timer_migration() && idle_cpu(cpu)) > > ? ? ? ? ? ? ? ?cpu = get_nohz_timer_target(); > > #endif > > ? ? ? ?new_base = per_cpu(tvec_bases, cpu); > > > > If you convert this to an if statement, will it still compile? ?Which will > > happen first, dead code elimination, or the warning that get_nohz_timer_target() > > is an implicit declaration because the definition in the .h file is also > > guarded by #ifdef CONFIG_NO_HZ? > > > I already exposed this case, but let's prove it: > > % grep CONFIG_SMP .config > # CONFIG_SMP is not set > > % git diff > diff --git a/kernel/timer.c b/kernel/timer.c > index fd61986..ea4a5ba 100644 > --- a/kernel/timer.c > +++ b/kernel/timer.c > @@ -681,10 +681,8 @@ __mod_timer(struct timer_list *timer, unsigned > long expires, > > cpu = smp_processor_id(); > > -#if defined(CONFIG_NO_HZ) && defined(CONFIG_SMP) > - if (!pinned && get_sysctl_timer_migration() && idle_cpu(cpu)) > + if (0 && 0 && !pinned && get_sysctl_timer_migration() && idle_cpu(cpu)) > cpu = get_nohz_timer_target(); > -#endif > new_base = per_cpu(tvec_bases, cpu); > > % gmake kernel/timer.o > CHK include/linux/version.h > CHK include/generated/utsrelease.h > CALL scripts/checksyscalls.sh > CC kernel/timer.o > kernel/timer.c: In function '__mod_timer': > kernel/timer.c:685:3: error: implicit declaration of function > 'get_nohz_timer_target' > gmake[1]: *** [kernel/timer.o] Error 1 > gmake: *** [kernel/timer.o] Error 2 because we do not define the inline function if the CONFIG_ is not define as we are supposed to do if we want to compile without ifdef everywhere Best Regards, J. -- 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/