[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADzpL0S04XTYoe4u7_WNgA6cw11uNw9uxiyyYCQ=cY-p-Z+sww@mail.gmail.com>
Date: Sun, 22 Apr 2012 21:20:35 -0500
From: Stephen Cameron <stephenmcameron@...il.com>
To: Paul Gortmaker <paul.gortmaker@...driver.com>
Cc: "Stephen M. Cameron" <scameron@...rdog.cce.hp.com>,
james.bottomley@...senpartnership.com, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org, matthew.gates@...com,
thenzl@...hat.com, akpm@...ux-foundation.org,
mikem@...rdog.cce.hp.com
Subject: Re: [PATCH 14/17] hpsa: use new IS_ENABLED macro
On Sun, Apr 22, 2012 at 1:12 PM, Paul Gortmaker
<paul.gortmaker@...driver.com> wrote:
> On Fri, Apr 20, 2012 at 11:07 AM, Stephen M. Cameron
> <scameron@...rdog.cce.hp.com> wrote:
>> From: Stephen M. Cameron <scameron@...rdog.cce.hp.com>
>>
>> Signed-off-by: Stephen M. Cameron <scameron@...rdog.cce.hp.com>
>
> You've not written a commit log, so I'm left guessing what the
> intended rationale is here. COMPAT, X86 and PCI_MSI are
> I believe all bool, so why make this change? To me it gives
> a misleading message that some level of modular awareness
> is needed here, when there really isn't any such need.
Well, I saw this commit go by: 69349c2dc01c489eccaa4c472542c08e370c6d7e
Using IS_ENABLED() within C (vs. within CPP #if statements) in its
current form requires us to actually define every possible bool/tristate
Kconfig option twice (__enabled_* and __enabled_*_MODULE variants).
[...]
and so I kind of thought IS_ENABLED is the new way to do that sort of thing.
Perhaps I'm wrong about that. Obviously the patch is not _needed_ for
things to work.
-- steve
--
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