Messages in this thread | | | From | Vineet Gupta <> | Subject | Re: using IS_ENABLED(CONFIG_xyz) effectively | Date | Mon, 16 Nov 2015 08:35:05 +0000 |
| |
Hi Geert,
On Monday 16 November 2015 01:58 PM, Geert Uytterhoeven wrote: > Hi Vineet, > > On Mon, Nov 16, 2015 at 9:00 AM, Vineet Gupta > <Vineet.Gupta1@synopsys.com> wrote: >> I've been using IS_ENABLED for some time and once in a while run into an issue >> which prevents seamless use. Hence posing this question to experts in the area. >> >> C macro processor evaluates the ensuing control block even if IS_ENABLED evaluates >> to false. This requires dummy #defines or worse still removing usage of IS_ENABLED >> altogether. >> >> e.g. In example below even for ARCOMPACT builds, we need the ARCV2 specific define >> ARCV2_IRQ_DEF_PRIO. >> >> void arch_cpu_idle(void) >> { >> if (is_isa_arcompact()) { <---- IS_ENABLED(CONFIG_ISA_ARCOMPACT) >> __asm__("sleep 0x3"); >> } else { >> const int arg = 0x10 | ARCV2_IRQ_DEF_PRIO; >> __asm__("sleep 0x10"); >> } >> } >> >> One could argue that the interface needs to be cleanly defined to not have such >> specific #defines in common code in first place. However sometime that becomes >> just too tedious. >> >> Is there a way to get around by this ? > Use #ifdef CONFIG_...? > > The advantage of IS_ENABLED() over #ifdef is that it allows compile-testing of > the disabled code path. Of course it should only be compiled if it makes > sense. And that's exactly what you're running into.
And I thought it was to de-uglify the code with same semantics - which doesn't seem to be the case ! Oh well !
Thx, -Vineet
| |