[Cocci] New release after 1.0.7?

[Luciano Coelho]

Hi,

Is there a plan for a new release after 1.0.7? 1.0.7 was not tagged and
no tarballs were released, so I'm not sure what is the status of it.
Additionally, I've had problems compiling it, and bisected it to this
commit:

commit 7ab8f01b63d7cdec988e5f05065f3c18fdab7319 (refs/bisect/bad)
Author: Thierry Martinez <***@inria.fr>
AuthorDate: Wed Jun 20 15:46:18 2018 +0200
Commit: Thierry Martinez <***@inria.fr>
CommitDate: Wed Jun 20 15:46:18 2018 +0200

Allow bytecode compilation for pyml/generate

This change generalizes a patch submitted by
Christopher Zimmermann <***@openbsd.org>
for allowing pyml/generate to be compiled by ocamlc if ocamlopt
is not available.

The rules are adapted from pyml-current/Makefile.

Nevertheless, the compilation problem I had seems to be fixed in the
latest master (commit 97695d059cd5).

We (in the Linux backports project) have made a change to support the
new attributes style[1], which was supposed to work with 1.0.6, but
that seems to be broken too.

We don't want to revert to using the pre-1.0.6 versions, so we are
waiting for new release to choose for our project. So, my question
again, can we expect a new stable release any time soon?

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/commit/?id=98272f479c2126a135dfcb12484e93d5888164ab

--
Cheers,
Luca.

[Julia Lawall]

On Tue, 14 Aug 2018, Luciano Coelho wrote:

> Hi,
>
> Is there a plan for a new release after 1.0.7? 1.0.7 was not tagged and
> no tarballs were released, so I'm not sure what is the status of it.
> Additionally, I've had problems compiling it, and bisected it to this
> commit:
>
> commit 7ab8f01b63d7cdec988e5f05065f3c18fdab7319 (refs/bisect/bad)
> Author: Thierry Martinez <***@inria.fr>
> AuthorDate: Wed Jun 20 15:46:18 2018 +0200
> Commit: Thierry Martinez <***@inria.fr>
> CommitDate: Wed Jun 20 15:46:18 2018 +0200
>
> Allow bytecode compilation for pyml/generate
>
> This change generalizes a patch submitted by
> Christopher Zimmermann <***@openbsd.org>
> for allowing pyml/generate to be compiled by ocamlc if ocamlopt
> is not available.
>
> The rules are adapted from pyml-current/Makefile.
>
> Nevertheless, the compilation problem I had seems to be fixed in the
> latest master (commit 97695d059cd5).
>
> We (in the Linux backports project) have made a change to support the
> new attributes style[1], which was supposed to work with 1.0.6, but
> that seems to be broken too.
>
> We don't want to revert to using the pre-1.0.6 versions, so we are
> waiting for new release to choose for our project. So, my question
> again, can we expect a new stable release any time soon?

Sorry, I'm not sure where 1.0.7 came from. I think that the compilation
issues should not be resolved, although if someone still sees problems
with the github version please report them. I'm surprised that the
attributes have degraded, since I don't recall a change with respect to
that recently. Could you send a .c and .cocci file that shows the
problem?

I would indeed like to make a release now that the compiations issues are
resolved and things seem more stable.

julia


>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/commit/?id=98272f479c2126a135dfcb12484e93d5888164ab
>
> --
> Cheers,
> Luca.
> _______________________________________________
> Cocci mailing list
> ***@systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>

[Julia Lawall]

> I'm not sure it's a regression, but I just couldn't get the attributes
> to work with 1.0.6 either with and without Johannes' changes to upgrade
> it to the 1.0.6 syntax.
>
> This is the cocci that doesn't work (which is supposed to work with
> 1.0.6):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/tree/patches/0027-genl-const/genl-const.cocci
>
> And, IIRC, this is the file that it's supposed to alter:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/wireless/nl80211.c

With the current version, I get the diff below. Is it what you expect?

julia

--- nl80211.c
+++ /tmp/cocci-output-11687-71a383-nl80211.c
@@ -48,7 +48,7 @@ enum nl80211_multicast_groups {
NL80211_MCGRP_TESTMODE /* keep last - ifdef! */
};

-static const struct genl_multicast_group nl80211_mcgrps[] = {
+static __genl_const struct genl_multicast_group nl80211_mcgrps[] = {
[NL80211_MCGRP_CONFIG] = { .name = NL80211_MULTICAST_GROUP_CONFIG },
[NL80211_MCGRP_SCAN] = { .name = NL80211_MULTICAST_GROUP_SCAN },
[NL80211_MCGRP_REGULATORY] = { .name = NL80211_MULTICAST_GROUP_REG },
@@ -12894,7 +12894,8 @@ static int nl80211_tx_control_port(struc
NL80211_FLAG_CHECK_NETDEV_UP)
#define NL80211_FLAG_CLEAR_SKB 0x20

-static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
+static int nl80211_pre_doit(__genl_const struct genl_ops *ops,
+ struct sk_buff *skb,
struct genl_info *info)
{
struct cfg80211_registered_device *rdev;
@@ -12956,7 +12957,8 @@ static int nl80211_pre_doit(const struct
return 0;
}

-static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
+static void nl80211_post_doit(__genl_const struct genl_ops *ops,
+ struct sk_buff *skb,
struct genl_info *info)
{
if (info->user_ptr[1]) {
@@ -12985,7 +12987,7 @@ static void nl80211_post_doit(const stru
}
}

-static const struct genl_ops nl80211_ops[] = {
+static __genl_const struct genl_ops nl80211_ops[] = {
{
.cmd = NL80211_CMD_GET_WIPHY,
.doit = nl80211_get_wiphy,

[Luciano Coelho]

On Tue, 2018-08-14 at 15:43 +0200, Julia Lawall wrote:
> > I'm not sure it's a regression, but I just couldn't get the
> > attributes
> > to work with 1.0.6 either with and without Johannes' changes to
> > upgrade
> > it to the 1.0.6 syntax.
> >
> > This is the cocci that doesn't work (which is supposed to work with
> > 1.0.6):
> >
> >
https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/tree/patches/0027-genl-const/genl-const.cocci
> >
> > And, IIRC, this is the file that it's supposed to alter:
> >
> >
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/wireless/nl80211.c
>
> With the current version, I get the diff below. Is it what you
> expect?
>
> julia
>
> --- nl80211.c
> +++ /tmp/cocci-output-11687-71a383-nl80211.c
> @@ -48,7 +48,7 @@ enum nl80211_multicast_groups {
> NL80211_MCGRP_TESTMODE /* keep last - ifdef! */
> };
>
> -static const struct genl_multicast_group nl80211_mcgrps[] = {
> +static __genl_const struct genl_multicast_group nl80211_mcgrps[] = {
> [NL80211_MCGRP_CONFIG] = { .name =
> NL80211_MULTICAST_GROUP_CONFIG },
> [NL80211_MCGRP_SCAN] = { .name = NL80211_MULTICAST_GROUP_SCAN
> },
> [NL80211_MCGRP_REGULATORY] = { .name =
> NL80211_MULTICAST_GROUP_REG },
> @@ -12894,7 +12894,8 @@ static int nl80211_tx_control_port(struc
> NL80211_FLAG_CHECK_NETDEV_UP)
> #define NL80211_FLAG_CLEAR_SKB 0x20
>
> -static int nl80211_pre_doit(const struct genl_ops *ops, struct
> sk_buff *skb,
> +static int nl80211_pre_doit(__genl_const struct genl_ops *ops,
> + struct sk_buff *skb,
> struct genl_info *info)
> {
> struct cfg80211_registered_device *rdev;
> @@ -12956,7 +12957,8 @@ static int nl80211_pre_doit(const struct
> return 0;
> }
>
> -static void nl80211_post_doit(const struct genl_ops *ops, struct
> sk_buff *skb,
> +static void nl80211_post_doit(__genl_const struct genl_ops *ops,
> + struct sk_buff *skb,
> struct genl_info *info)
> {
> if (info->user_ptr[1]) {
> @@ -12985,7 +12987,7 @@ static void nl80211_post_doit(const stru
> }
> }
>
> -static const struct genl_ops nl80211_ops[] = {
> +static __genl_const struct genl_ops nl80211_ops[] = {
> {
> .cmd = NL80211_CMD_GET_WIPHY,
> .doit = nl80211_get_wiphy,

Yes, this looks right! So it seems to be working with 1.0.8. :P

Thanks a lot for checking and helping here.

--
Cheers,
Luca.

[Johannes Berg]

On Tue, 2018-08-14 at 17:39 +0300, Luciano Coelho wrote:
>
> Yes, this looks right! So it seems to be working with 1.0.8. :P

There is no 1.0.8 though.

Julia, can you clear up the confusion with 1.0.7 and perhaps make a
1.0.8 release? Right now, there's only a very old (1.0.4 I think)
release that can do this at all, but it isn't compatible with the
current syntax. We'd like to have a release that has this ability so we
can check for the (minimum) version.

Thanks,
johannes

[Johannes Berg]

Julia,

On Tue, 2018-08-14 at 15:19 +0200, Julia Lawall wrote:

> Sorry, I'm not sure where 1.0.7 came from. [...]

> I would indeed like to make a release now that the compiations issues are
> resolved and things seem more stable.

Were you able to clear this up?

I see now that the website advertises the 1.0.7 release, however

* it's not tagged in git(hub) - all previous releases have a tag
* commit c1522bde ("Release 1.0.7") is NOT what's released as 1.0.7 on
the website
* it *looks* like the actual 1.0.7 release was cut from a much newer
git commit, likely with the fix?

johannes

[Julia Lawall]

On Mon, 10 Sep 2018, Johannes Berg wrote:

> Julia,
>
> On Tue, 2018-08-14 at 15:19 +0200, Julia Lawall wrote:
>
> > Sorry, I'm not sure where 1.0.7 came from. [...]
>
> > I would indeed like to make a release now that the compiations issues are
> > resolved and things seem more stable.
>
> Were you able to clear this up?
>
> I see now that the website advertises the 1.0.7 release, however
>
> * it's not tagged in git(hub) - all previous releases have a tag
> * commit c1522bde ("Release 1.0.7") is NOT what's released as 1.0.7 on
> the website
> * it *looks* like the actual 1.0.7 release was cut from a much newer
> git commit, likely with the fix?

I'm still somewhat lost about it. There is now a 1.0.7 source code on the
web site, which is the proper 1.0.7. But the binaries on the web site are
still 1.0.6. The previous thing that seemed to be 1.0.7 was an accidental
side effect of a test of the release script. I think that my engineer was
waiting me to confirm something before putting a tag in github, but I'm
not sure what I was to confirm. I will try to clear everything up. But
the source code on the Coccinelle website is the official 1.0.7.

julia

[Johannes Berg]

On Wed, 2018-09-12 at 12:14 +0200, Julia Lawall wrote:

> > I see now that the website advertises the 1.0.7 release, however
> >
> > * it's not tagged in git(hub) - all previous releases have a tag
> > * commit c1522bde ("Release 1.0.7") is NOT what's released as 1.0.7 on
> > the website
> > * it *looks* like the actual 1.0.7 release was cut from a much newer
> > git commit, likely with the fix?
>
> There is now a tag for the official release of 1.0.7 in github.

Great, thanks!

johannes

[SF Markus Elfring]

> https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/tree/patches/0027-genl-const/genl-const.cocci

How do you think about to try the following SmPL script variant out?

@replacement@
@@
-const
+__genl_const
struct
(
genl_multicast_group
|genl_ops
)


Regards,
Markus

[Julia Lawall]

On Wed, 15 Aug 2018, SF Markus Elfring wrote:

> > https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/tree/patches/0027-genl-const/genl-const.cocci
>
> How do you think about to try the following SmPL script variant out?
>
> @replacement@
> @@
> -const
> +__genl_const
> struct
> (
> genl_multicast_group
> |genl_ops
> )

This is rejected by the semantic patch parser.

julia

[SF Markus Elfring]

>> How do you think about to try the following SmPL script variant out?
>>
>> @replacement@
>> @@
>> -const
>> +__genl_const
>> struct
>> (
>> genl_multicast_group
>> |genl_ops
>> )
>
> This is rejected by the semantic patch parser.

Can my update suggestion make sense if the parsing software
will be adjusted anyhow?

Does this variant need a small adjustment to get it working
with the current tool version?

Regards,
Markus

[Julia Lawall]

On Wed, 15 Aug 2018, SF Markus Elfring wrote:

> >> How do you think about to try the following SmPL script variant out?
> >>
> >> @replacement@
> >> @@
> >> -const
> >> +__genl_const
> >> struct
> >> (
> >> genl_multicast_group
> >> |genl_ops
> >> )
> >
> > This is rejected by the semantic patch parser.
>
> Can my update suggestion make sense if the parsing software
> will be adjusted anyhow?
>
> Does this variant need a small adjustment to get it working
> with the current tool version?

I don't know. It may be large and it may be small. You are welcome to
try to change it if you want. Otherwise it doesn't seem urgent.

julia