Re: [PATCH] coccinelle: api: detect duplicate chip data arrays

From: Julia Lawall
Date: Thu Oct 05 2017 - 15:40:14 EST




On Thu, 5 Oct 2017, Joe Perches wrote:

> On Thu, 2017-10-05 at 21:19 +0200, Julia Lawall wrote:
> > On Thu, 5 Oct 2017, Joe Perches wrote:
> > > On Thu, 2017-10-05 at 21:13 +0200, Julia Lawall wrote:
> > > > On Fri, 6 Oct 2017, Masahiro Yamada wrote:
> > > > > 2017-10-01 21:42 GMT+09:00 Julia Lawall <Julia.Lawall@xxxxxxx>:
> > > > > > This semantic patch detects duplicate arrays declared using BQ27XXX_DATA
> > > > > > within a single structure. It is currently specific to the file
> > > > > > drivers/power/supply/bq27xxx_battery.c.
> > > > > > Signed-off-by: Julia Lawall <Julia.Lawall@xxxxxxx>
> > > > > Applied to linux-kbuild/misc.
> > > > Thanks for picking it up.
> > > If it is specific to one file, why not just run it
> > > and post the resultant patch? Why have it in tree?
> > I guess that they anticipate that the data may change in the future?
>
> Aren't you the script author Julia? Who is the "they"?

Liam, etc.

> I think having a script for a single file unnecessary.
>
> btw: spatch 1.7 doesn't seem to have a tag in git
>
> From the script:
>
> // Requires: 1.0.7
>
> Assuming this is correct, then this doesn't even run today
> except maybe on your system.

It runs on the current github version. If you don't have the github
version it will suffer from false negatives, but nothing will break.

julia

> $ git show
> commit 0bf53049e64295e8ddb625e853134f49568f4bc3
> Merge: 446dc66f8b98 d599cc6a75e0
> Author: julia <julia.lawall@xxxxxxx>
> Date:   Sun Oct 1 22:44:34 2017 +0200
>
>     Merge git+ssh://palace.lip6.fr/var/git/coccinelle
>
> $
>
> When I build this, the version is 1.0.6
>
> $ /usr/local/bin/spatch --version
> spatch version 1.0.6-00033-g23cca0a238c2 compiled with OCaml version 4.02.3
> Flags passed to the configure script: [none]
> Python scripting support: yes
> Syntax of regular expresssions: PCRE
>
> > If id-utils is used, Coccinelle will completely ignore files that don't
> > contain BQ27XXX_DATA, so the rule will have essentially no performance
> > impact. If there is no indexing, it will only "grep" for BQ27XXX_DATA,
> > not actually parse the files that don't contain it. So there is not much
> > performance impact even in that case.
>
> I'm not sure that matters.
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>