Messages in this thread | | | Date | Tue, 28 Jun 2022 10:24:59 -0400 | From | Paul Gortmaker <> | Subject | Re: [RFC][PATCH] kconfig: Add implicit CONFIG_ prefix to IS_ENABLED() and co |
| |
[Re: [RFC][PATCH] kconfig: Add implicit CONFIG_ prefix to IS_ENABLED() and co] On 28/06/2022 (Tue 13:19) Arnd Bergmann wrote:
> On Tue, Jun 28, 2022 at 11:56 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > Since IS_ENABLED() (and friends) are clearly meant to be used on > > CONFIG_foo symbols and IS_ENABLED(CONFIG_ is so long and almost an > > tautology, allow the more compact usage of: IS_ENABLED(foo). > > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> > > I'd prefer to keep the more verbose usage, mainly because it makes it easier > to grep for a symbol. If today you do 'git grep CONFIG_PM_SLEEP', you find > all instances in Makefile, in #ifdef and in IS_ENABLED(), though not the > references in Kconfig language, which leave out the prefix.
TL;DR - me too.
I confess that I do the same thing - I grep for CONFIG_FOO to find the consumers, and "config FOO" to find the provider.
So while I can appreciate the value of removing verbosity, this will impact workflows of average people out there.
Doing a grep for "PCI" is practically worthless. Having to grep for both CONFIG_PCI and IS_ENABLED\(PCI will inevitably annoy people when they realize they missed a code path needing an update because they only searched for the former.
Paul. --
> > If we remove the prefix for IS_ENABLED(), the same grep fails to get > all the results, while searching for the substring without the CONFIG_ > prefix can end up finding false-positives by finding longer strings (e.g. > CONFIG_DEBUG_STACKOVERFLOW vs > CONFIG_HAVE_DEBUG_STACKOVERFLOW). > > Arnd
| |