From: Peter Zijlstra <peterz@infradead.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
mmarek@suse.cz, Paul Gortmaker <paul.gortmaker@windriver.com>,
Mike Rapoport <rppt@kernel.org>, Borislav Petkov <bp@alien8.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] kconfig: Add implicit CONFIG_ prefix to IS_ENABLED() and co
Date: Tue, 28 Jun 2022 14:01:31 +0200 [thread overview]
Message-ID: <Yrrtm0rRzLMCzKiM@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAK8P3a2XfzQo6emT4pXXxAjWewdP2LiAe2fOskFf-0suSmBJQQ@mail.gmail.com>
On Tue, Jun 28, 2022 at 01:19:17PM +0200, 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.
Which is why I never grep for the CONFIG_ thing to begin with, it misses
the Kconfig site.
> 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).
Me being used to that doesn't consider that a real issue :-) I'd much
rather have the somewhat shorter IS_ENABLED() things.
next prev parent reply other threads:[~2022-06-28 12:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 9:56 [RFC][PATCH] kconfig: Add implicit CONFIG_ prefix to IS_ENABLED() and co Peter Zijlstra
2022-06-28 10:28 ` Mike Rapoport
2022-06-28 11:19 ` Arnd Bergmann
2022-06-28 12:01 ` Peter Zijlstra [this message]
2022-06-28 12:09 ` Masahiro Yamada
2022-06-28 12:17 ` Rasmus Villemoes
2022-06-28 14:24 ` Paul Gortmaker
2022-06-29 14:37 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yrrtm0rRzLMCzKiM@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mmarek@suse.cz \
--cc=paul.gortmaker@windriver.com \
--cc=rppt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox