From: Paul Bolle <pebolle@tiscali.nl>
To: Valentin Rothberg <valentinrothberg@gmail.com>
Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
stefan.hengelein@fau.de
Subject: Re: [PATCH v3] checkkconfigsymbols.sh: reimplementation in python
Date: Mon, 22 Sep 2014 10:24:09 +0200 [thread overview]
Message-ID: <1411374249.11208.15.camel@x220> (raw)
In-Reply-To: <1411371813.3460.34.camel@nebuchadnezzar>
Hi Valentin,
On Mon, 2014-09-22 at 09:43 +0200, Valentin Rothberg wrote:
> On dim., 2014-09-21 at 23:28 +0200, Paul Bolle wrote:
> > Valentin Rothberg schreef op zo 21-09-2014 om 21:53 [+0200]:
> > > Furthermore, it generates false positives (4 of 526 in v3.17-rc1).
> >
> > Curiosity: what are those four false positives?
>
> 1) /arch/cris/kernel/module.c: ETRAX_KMALLOCED_MODULES (defined in
> arch/cris/Kconfig)
This probably because
symb_bare=`echo $symb | sed -e 's/_MODULE//'`
in the shell script you removed should read (something untested like):
symb_bare=`echo $symb | sed -e 's/_MODULE$//'`
> 2) ./lib/Makefile: TEST_MODULE (defined in lib/Kconfig.debug)
TEST_MODULE is an awkward name for a Kconfig symbol. My local script has
it special cased.
> 3,4) ./include/linux/module.h, ./kernel/module.c: DEBUG_SET_MODULE_RONX
> (defined in arch/{s390,arm,x86}/Kconfig.debug)
See above.
> > > This patch replaces the shell script with an implementation in Python,
> > > which:
> > > (a) detects the same bugs, but does not report false positives
> >
> > Depends a bit on the definition of false positives. Ie, the hit for
> > ./arch/sh/kernel/head_64.S: CACHE_
> >
> > is caused by
> > #error preprocessor flag CONFIG_CACHE_... not recognized!
> >
> > Should that line, and similar lines, be changed?
>
> I consider a false positive to actually be defined in Kconfig. The
> feature in your example does not really apply to the naming convention
> of Kconfig features ("..."), so that our regex does not match it.
But your python script does report it, doesn't it?
> However, the regex matches "CONFIG_X86_". I shall change the regex to
> not accept strings ending with "_", so that such cases are not reported.
> > > +# REGEX EXPRESSIONS
> > > +OPERATORS = r"&|\(|\)|\||\!"
> > > +FEATURE = r"\w*[A-Z]{1}\w*"
> > > +FEATURE_DEF = r"^\s*(menu){,1}config\s+" + FEATURE + r"\s*"
> > > +EXPR = r"(" + OPERATORS + r"|\s|" + FEATURE + r")*"
> > > +STMT = r"^\s*(if|select|depends\s+on)\s+" + EXPR
> >
> > "depends on" with multiple spaces?
> > > +
> > > +# REGEX OBJECTS
> > > +REGEX_FILE_KCONFIG = re.compile(r"Kconfig[\.\w+\-]*$")
> > > +REGEX_FILE_SOURCE = re.compile(r"\.[cSh]$")
New observation: this causes the script to skip text files, shell
scripts, etc, doesn't it?
> > > +REGEX_FILE_MAKE = re.compile(r"Makefile|Kbuild[\.\w+]*$")
> > > +REGEX_FEATURE = re.compile(r"(" + FEATURE + r")")
> > > +REGEX_FEATURE_DEF = re.compile(FEATURE_DEF)
> > > +REGEX_CPP_FEATURE = re.compile(r"\W+CONFIG_(" + FEATURE + r")[.]*")
> >
> > There are a few uses of "-DCONFIG_[...]" in Makefiles. This will miss
> > those, won't it? That's not bad, per se, but a comment why you're
> > skipping those might be nice. Or are those caught too, somewhere else?
>
> I was not aware of such uses, thanks. It seems important to cover them
> too. Does this prefix has a certain purpose?
It is, in short, a way to define preprocessor macros from the GCC
command line (see info gcc).
> > > +REGEX_KCONFIG_EXPR = re.compile(EXPR)
> > > +REGEX_KCONFIG_STMT = re.compile(STMT)
> > > +REGEX_KCONFIG_HELP = re.compile(r"^[\s|-]*help[\s|-]*")
> >
> > Won't "^\s\+(---help---|help)$" do? Might help catch creative variants
> > of the help statement (we had a few in the past).
>
> Yes, your regex is more robust. Thanks!
But it seems I should not have escaped the plus. Please check.
Paul Bolle
next prev parent reply other threads:[~2014-09-22 8:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-20 14:15 [PATCH] checkkconfigsymbols.sh: reimplementation in python Valentin Rothberg
2014-09-21 19:39 ` [PATCH v2] " Valentin Rothberg
2014-09-21 19:53 ` [PATCH v3] " Valentin Rothberg
2014-09-21 21:28 ` Paul Bolle
2014-09-22 7:43 ` Valentin Rothberg
2014-09-22 8:24 ` Paul Bolle [this message]
2014-09-22 8:45 ` Valentin Rothberg
2014-09-22 9:06 ` Paul Bolle
2014-09-22 14:58 ` [PATCH v4] " Valentin Rothberg
2014-09-23 16:45 ` Paul Bolle
2014-09-27 12:57 ` [PATCH v5] " Valentin Rothberg
2014-09-27 14:30 ` [PATCH v6] " Valentin Rothberg
2014-09-28 15:55 ` [PATCH v7] " Valentin Rothberg
2014-09-29 10:28 ` Paul Bolle
2014-09-29 12:08 ` Valentin Rothberg
2014-09-29 12:45 ` Paul Bolle
2014-09-29 14:47 ` Michal Marek
2014-09-29 16:21 ` Paul Bolle
2014-09-29 17:05 ` [PATCH v8] " Valentin Rothberg
2014-10-01 14:58 ` Michal Marek
2014-10-04 9:29 ` Valentin Rothberg
2014-10-08 13:39 ` Michal Marek
2014-10-19 15:30 ` Valentin Rothberg
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=1411374249.11208.15.camel@x220 \
--to=pebolle@tiscali.nl \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefan.hengelein@fau.de \
--cc=valentinrothberg@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.