Re: [PATCH] checkkconfigsymbols.py: filter reports for tools/

[Paul Bolle <pebolle@tiscali.nl>]

On Tue, 2015-03-03 at 08:55 +0100, Valentin Rothberg wrote:
> On Tue, Mar 3, 2015 at 1:57 AM, Paul Bolle <pebolle@tiscali.nl> 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