Re: [PATCH] checkkconfigsymbols.py: filter reports for tools/
From: Paul Bolle
Date: Tue Mar 03 2015 - 17:52:15 EST
On Tue, 2015-03-03 at 08:55 +0100, Valentin Rothberg wrote:
> On Tue, Mar 3, 2015 at 1:57 AM, Paul Bolle <pebolle@xxxxxxxxxx> wrote:
> > On Wed, 2015-02-25 at 15:15 +0100, Valentin Rothberg wrote:
> > This patch was triggered by perf changes that hit next-20150225, wasn't
> > it? If so, we might want to find out why the perf people need to use
>
> Yes, it was in next-20150225. However, more recent changes have the
> same problem. I fear it get's worse for us : )
>
> > their
> > "$(call detected,CONFIG_EXAMPLE)"
> >
> > hack. Especially because that hack is also used on existing Kconfig
> > symbols (I spotted X86, X86_64, AUDIT, and NUMA). And the usage of both
> > valid Kconfig macros and faux Kconfig macros in that hack looks odd to
> > me.
>
> AFAIU it's independent from Kconfig / Kbuild. The usage of Kconfig
> symbols seems completely random to me.
I think the entire "call detected" mechanism might as well use, say,
DETECTED_ for a prefix. That would solve our worries. Please have a look
at that hack, and see if I got that right. In that case we might as well
send a patch to do something like that and see if the perf developers
bark.
> Ignoring tools entirely also seems a little too much, since some tools
> are still Kconfig sensitive. Hence, I vote to ignore only perf:
>
> + gitfile.startswith("tools/perf"):
My suggestion to only use "tools/perf/config/Makefile" was silly, and
you missed an opportunity to mock me.
tools/ is special. I'm unsure how to handle it. Assuming
checkkconfigsymbols.py will not be used by the "checker complains, so
patches must be sent" crowd, I suggest to do nothing. But it's your
script, so I defer to your decision.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/