From: Julia Lawall <julia.lawall@lip6.fr>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Gilles Muller <Gilles.Muller@lip6.fr>,
nicolas.palix@imag.fr, mmarek@suse.com,
linux-kernel@vger.kernel.org, cocci@systeme.lip6.fr
Subject: Re: [PATCH 4/4] scripts/coccinelle: require coccinelle >= 1.0.4 on device_node_continue.cocci
Date: Wed, 15 Jun 2016 18:52:27 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.10.1606151850210.2887@hadrien> (raw)
In-Reply-To: <20160615164646.GT11948@wotan.suse.de>
On Wed, 15 Jun 2016, Luis R. Rodriguez wrote:
> On Wed, Jun 15, 2016 at 06:11:57PM +0200, Julia Lawall wrote:
> >
> >
> > On Wed, 15 Jun 2016, Luis R. Rodriguez wrote:
> >
> > > On Wed, Jun 15, 2016 at 05:55:34PM +0200, Julia Lawall wrote:
> > > >
> > > >
> > > > On Wed, 15 Jun 2016, Luis R. Rodriguez wrote:
> > > >
> > > > > On Wed, Jun 15, 2016 at 10:43:30AM +0200, Julia Lawall wrote:
> > > > > > How about the following, since Coccinelle knows what its version is?
> > > > > > This could of course be implemented in python as well.
> > > > > >
> > > > > > julia
> > > > > >
> > > > > > diff --git a/docs/Coccilib.3cocci b/docs/Coccilib.3cocci
> > > > > > index 0e4fbb8..ca5b061 100644
> > > > > > --- a/docs/Coccilib.3cocci
> > > > > > +++ b/docs/Coccilib.3cocci
> > > > > > @@ -232,6 +232,15 @@ is the empty list if spatch is not currently working on any file (eg,
> > > > > > in an initialize or finalize rule).
> > > > > > .sp
> > > > > >
> > > > > > +.I val cocci_version
> > > > > > +:
> > > > > > +.B unit -> string
> > > > > > +.sp
> > > > > > +Returns the a string indicating the current version. Note that if
> > > > > > +Coccinelle has been modified since a release, the version number will be
> > > > > > +postfixed with "-dirty".
> > > > > > +.sp
> > > > > > +
> > > > > > .I val print_main
> > > > > > :
> > > > > > .B ?color:string -> string -> pos list -> unit
> > > > > > diff --git a/ocaml/coccilib.ml b/ocaml/coccilib.ml
> > > > > > index f60c6b2..2f352d8 100644
> > > > > > --- a/ocaml/coccilib.ml
> > > > > > +++ b/ocaml/coccilib.ml
> > > > > > @@ -168,6 +168,8 @@ let dir () = !Flag.dir
> > > > > >
> > > > > > let files () = !Flag.currentfiles
> > > > > >
> > > > > > +let cocci_version () = Config.version
> > > > > > +
> > > > > > (* ---------------------------------------------------------------------- *)
> > > > > > (* org mode *)
> > > > > >
> > > > > >
> > > > >
> > > > > Anything to *only* get the version instead of a long list is nice, right now
> > > > > spatch --version spits out:
> > > > >
> > > > > spatch version 1.0.5 compiled with OCaml version 4.02.3
> > > > > Flags passed to the configure script: [none]
> > > > > Python scripting support: yes
> > > > > Syntax of regular expresssions: PCRE
> > > > >
> > > > > The Python library just parses the 3rd item at the top so it can extract
> > > > > the version. But surely if spatch --version-only was available we'd use
> > > > > that instead a well.
> > > > >
> > > > > Other than this though how can we require coccinelle version checks per
> > > > > SmPL file cleanly and also what should we do to make it backward compatible
> > > > > with older versions of coccinelle?
> > > >
> > > > I'm not sure that being backward compatible with older versions of
> > > > Coccinelle is worth adding new libraries to the Linux kernel, and adding
> > > > unpleasant python code to semantic patches.
> > >
> > > True. I'm more than happy to not have to add this crap.
> > >
> > > > The above ocaml code just produces eg 1.0.5 or 1.0.5-dirty. I could drop
> > > > the -dirty at the coccilib level, if that seems desirable.
> > >
> > > This is when spatch --cocci_version is passed ?
> >
> > Perhaps it wasn't clear enough from the above nroff and ocaml code. I
> > added a function Coccilib.version() that returns eg either 1.0.5 or
> > 1.0.5-dirty. Such a function could be implemented for python as well.
> >
> > >
> > > Its still unclear how we can require in a clean way coccinelle version
> > > requirements in SmPL patches with this. Can you clarify?
> >
> > Test the string that it returns and exit. Like you are doing, but no need
> > for adding new libraries to the kernel.
>
> Ah then that's indeed welcome, however another function would be best too:
>
> Coccilib.version_reqs() which lets us say what the requirement is and it
> would return true or false, false when the req is not met.
I'm not so fond of this. It seems like a very specific use case.
I really think this should be managed by coccicheck, in the same way as
the options.
julia
next prev parent reply other threads:[~2016-06-15 16:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-14 22:10 [PATCH 0/4] scripts: add basic python version library and use it Luis R. Rodriguez
2016-06-14 22:10 ` [PATCH 1/4] coccicheck: propagate error and stop processing after first error Luis R. Rodriguez
2016-06-14 22:10 ` [PATCH 2/4] scripts: add reqs python library Luis R. Rodriguez
2016-06-15 6:06 ` Julia Lawall
2016-06-15 16:04 ` Luis R. Rodriguez
2016-06-15 7:50 ` Michal Marek
2016-06-15 16:02 ` Luis R. Rodriguez
2016-06-15 19:11 ` Michal Marek
2016-06-15 20:26 ` Luis R. Rodriguez
2016-06-15 20:31 ` Julia Lawall
2016-06-15 12:01 ` Aw: [Cocci] " SF Markus Elfring
2016-06-15 15:51 ` Luis R. Rodriguez
2016-06-14 22:10 ` [PATCH 3/4] coccicheck: enable use of the kernel's " Luis R. Rodriguez
2016-06-15 7:51 ` Michal Marek
2016-06-15 15:43 ` Luis R. Rodriguez
2016-06-14 22:10 ` [PATCH 4/4] scripts/coccinelle: require coccinelle >= 1.0.4 on device_node_continue.cocci Luis R. Rodriguez
2016-06-15 6:08 ` Julia Lawall
2016-06-15 15:45 ` Luis R. Rodriguez
2016-06-15 8:43 ` Julia Lawall
2016-06-15 15:49 ` Luis R. Rodriguez
2016-06-15 15:55 ` Julia Lawall
2016-06-15 16:06 ` SF Markus Elfring
2016-06-15 16:08 ` [PATCH 4/4] " Luis R. Rodriguez
2016-06-15 16:11 ` Julia Lawall
2016-06-15 16:46 ` Luis R. Rodriguez
2016-06-15 16:52 ` Julia Lawall [this message]
2016-06-15 19:08 ` Luis R. Rodriguez
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=alpine.DEB.2.10.1606151850210.2887@hadrien \
--to=julia.lawall@lip6.fr \
--cc=Gilles.Muller@lip6.fr \
--cc=cocci@systeme.lip6.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mmarek@suse.com \
--cc=nicolas.palix@imag.fr \
/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