Re: [Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Feb 10, 2016 at 7:44 AM, Olaf Hering  wrote:
> On Wed, Feb 10, Luis R. Rodriguez wrote:
>
>> cherry picks for fixes or huge interest to keep it compatible with latest
>> compilers qemu-xen-traditional seems to be more of a liability than a
>
> Hey, this is about gnutls, not gcc!

Actually no, I also had backported another fix which I submitted part
of this series, and it is present as of this release:

mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
98d23704138e0be17a3ed9eb2631077bf92cc028
v1.1-rc0~785

How are fixes of interested backported regularly for this to make it
reasonable to at least keep this as a viable option which at least
compiles? Only compiling is one thing, how are security fixes
backported proactively?

 Luis
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Feb 10, 2016 at 09:46:30AM +, Ian Campbell wrote:
> On Tue, 2016-02-09 at 19:04 -0800, Luis R. Rodriguez wrote:
> > On Tue, Feb 9, 2016 at 10:23 AM, Olaf Hering  wrote:
> > > On Tue, Feb 09, Luis R. Rodriguez wrote:
> > > 
> > > > Thanks so it seems the other option is to bump the release, can that
> > > > be decided? What's the process for deciding that?
> > > 
> > > Which release should be bumped?
> > 
> > In so far as TLS is concerned:
> > 
> > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> > f40d55081667a716312b9a8b6e13835c4074f56b
> > v1.0-rc0~325
> > 
> > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> > 7d2a929feba319c18603e324b1750830d6c8b7a1
> > v1.5.0-rc0~660
> > 
> > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> > d321e1e526810
> > v2.5.0-rc0~125^2~2
> > 
> > As for the other fix I backported for the existing release carried:
> > 
> > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> > 98d23704138e0be17a3ed9eb2631077bf92cc028
> > v1.1-rc0~785
> > 
> > I wanted to see what is the current version on Xen for
> > qemu-xen-traditional-dir-remote thing, is this the right way to check
> > what version is on /tools/qemu-xen-traditional-dir-remote ?
> > 
> > mcgrof@ergon ~/devel/xen/tools/qemu-xen-traditional-dir-remote
> > (git::dummy)$ cat VERSION
> > 0.10.2
> > 
> > If so.. I'm scared.
> 
> qemu-xen-traditional Device Model is the old Xen fork which is maintained
> only in order to support old VMs which expect the hardware environment
> provided by that old version of QEMU.
> 
> The default Device Model since Xen 4.3 has been "qemu-xen", which is our
> name for QEMU upstream. Xen 4.6 shipped with a bundled QEMU 2.2.1, but
> users (and distros) are free to supply their own (see configure's --with-
> system-qemu option) instead.
> 
> Hopefully it is clear therefore why just upgrading qemu-xen-traditional to
> a newer QEMU is not an option (or rather, that already exists and is the
> default via qemu-xen)
> 
> If you aren't interested in supporting VMs installed on very old versions
> of Xen then it would be reasonable to:
> ./configure --disable-qemu-traditional
> and avoid it all together.
> 
> So far as making qemu-xen-trad compatible with gcc5 while still retaining
> support for building on the oldest platforms we want to support (whatever
> those are) I have no real opinion, but it seems some sort of
> abstraction/shim layer would be needed to satisfy both cases.

Thanks for the details! If there is no proactive mechanism to scrape for
cherry picks for fixes or huge interest to keep it compatible with latest
compilers qemu-xen-traditional seems to be more of a liability than a
helper, would it be too irrational to propose to just burry it and mark
it as no longer supported?

  Luis
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] coccinelle: add style check for assignment in if

[Joe Perches]

On Tue, 2016-02-09 at 13:55 +0100, SF Markus Elfring wrote:
> > > Would you like to consider also the reuse of SmPL variables
> > > like "org" and "report"?
> > 
> > I think that there is no point for these things, because checkpatch
> > already gives warnings about this issue.
> 
> Can the check result display be more convenient from the semantic
> patch script interface in comparison to the other tool?

-ENOPARSE.  More detail please.

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] [PATCH] Coccinelle: Add api/setup_timer.cocci

[Vaishali Thakkar]

Use the timer API function setup_timer instead of structure field
assignments to initialize a timer.

Signed-off-by: Vaishali Thakkar 
---
 scripts/coccinelle/api/setup_timer.cocci | 199 +++
 1 file changed, 199 insertions(+)
 create mode 100644 scripts/coccinelle/api/setup_timer.cocci

diff --git a/scripts/coccinelle/api/setup_timer.cocci 
b/scripts/coccinelle/api/setup_timer.cocci
new file mode 100644
index 000..8ee0ac3
--- /dev/null
+++ b/scripts/coccinelle/api/setup_timer.cocci
@@ -0,0 +1,199 @@
+/// Use setup_timer function instead of initializing timer with the function
+/// and data fields
+// Confidence: High
+// Copyright: (C) 2016 Vaishali Thakkar, Oracle. GPLv2
+// Options: --no-includes --include-headers
+// Keywords: init_timer, setup_timer
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+@match_immediate_function_data_after_init_timer
+depends on patch && !context && !org && !report@
+expression e, func, da;
+@@
+
+-init_timer ();
++setup_timer (, func, da);
+
+(
+-e.function = func;
+-e.data = da;
+|
+-e.data = da;
+-e.function = func;
+)
+
+@match_function_and_data_after_init_timer
+depends on patch && !context && !org && !report@
+expression e1, e2, e3, e4, e5, a, b;
+@@
+
+-init_timer ();
++setup_timer (, a, b);
+
+... when != a = e2
+when != b = e3
+(
+-e1.function = a;
+... when != b = e4
+-e1.data = b;
+|
+-e1.data = b;
+... when != a = e5
+-e1.function = a;
+)
+
+@r1 exists@
+identifier f;
+position p;
+@@
+
+f(...) { ... when any
+  init_timer@p(...)
+  ... when any
+}
+
+@r2 exists@
+identifier g != r1.f;
+struct timer_list t;
+expression e8;
+@@
+
+g(...) { ... when any
+  t.data = e8
+  ... when any
+}
+
+// It is dangerous to use setup_timer if data field is initialized
+// in another function.
+
+@script:python depends on r2@
+p << r1.p;
+@@
+
+cocci.include_match(False)
+
+@r3 depends on patch && !context && !org && !report@
+expression e6, e7, c;
+position r1.p;
+@@
+
+-init_timer@p ();
++setup_timer (, c, 0UL);
+... when != c = e7
+-e6.function = c;
+
+// 
+
+@match_immediate_function_data_after_init_timer_context
+depends on !patch && (context || org || report)@
+expression da, e, func;
+position j0, j1, j2;
+@@
+
+* init_timer@j0 ();
+(
+* e@j1.function = func;
+* e...@j2.data = da;
+|
+* e...@j1.data = da;
+* e@j2.function = func;
+)
+
+@match_function_and_data_after_init_timer_context
+depends on !patch &&
+!match_immediate_function_data_after_init_timer_context &&
+(context || org || report)@
+expression a, b, e1, e2, e3, e4, e5;
+position j0, j1, j2;
+@@
+
+* init_timer@j0 ();
+... when != a = e2
+when != b = e3
+(
+* e1@j1.function = a;
+... when != b = e4
+* e...@j2.data = b;
+|
+* e...@j1.data = b;
+... when != a = e5
+* e1@j2.function = a;
+)
+
+@r3_context depends on !patch &&
+!match_immediate_function_data_after_init_timer_context &&
+!match_function_and_data_after_init_timer_context &&
+(context || org || report)@
+expression c, e6, e7;
+position r1.p;
+position j0, j1;
+@@
+
+* init_timer@j0@p ();
+... when != c = e7
+* e6@j1.function = c;
+
+// 
+
+@script:python match_immediate_function_data_after_init_timer_org
+depends on org@
+j0 << match_immediate_function_data_after_init_timer_context.j0;
+j1 << match_immediate_function_data_after_init_timer_context.j1;
+j2 << match_immediate_function_data_after_init_timer_context.j2;
+@@
+
+msg = "Use setup_timer function."
+coccilib.org.print_todo(j0[0], msg)
+coccilib.org.print_link(j1[0], "")
+coccilib.org.print_link(j2[0], "")
+
+@script:python match_function_and_data_after_init_timer_org depends on org@
+j0 << match_function_and_data_after_init_timer_context.j0;
+j1 << match_function_and_data_after_init_timer_context.j1;
+j2 << match_function_and_data_after_init_timer_context.j2;
+@@
+
+msg = "Use setup_timer function."
+coccilib.org.print_todo(j0[0], msg)
+coccilib.org.print_link(j1[0], "")
+coccilib.org.print_link(j2[0], "")
+
+@script:python r3_org depends on org@
+j0 << r3_context.j0;
+j1 << r3_context.j1;
+@@
+
+msg = "Use setup_timer function."
+coccilib.org.print_todo(j0[0], msg)
+coccilib.org.print_link(j1[0], "")
+
+// 
+
+@script:python match_immediate_function_data_after_init_timer_report
+depends on report@
+j0 << match_immediate_function_data_after_init_timer_context.j0;
+j1 << match_immediate_function_data_after_init_timer_context.j1;
+@@
+
+msg = "Use setup_timer function for function on line %s." % (j1[0].line)
+coccilib.report.print_report(j0[0], msg)
+
+@script:python match_function_and_data_after_init_timer_report depends on 
report@
+j0 << match_function_and_data_after_init_timer_context.j0;
+j1 << match_function_and_data_after_init_timer_context.j1;
+@@
+
+msg = "Use setup_timer 

Re: [Cocci] coccinelle: add style check for assignment in if

[SF Markus Elfring]

>> Can the check result display be more convenient from the semantic
>> patch script interface in comparison to the other tool?
> 
> -ENOPARSE.  More detail please.

Kris Borer suggested a SmPL script which can generate (only) patches
so far by the usual application of the Coccinelle software.
I assume that this approach was limited just because Julia Lawall
indicated that this functionality would be sufficient for a while.

The documentation for the command "make coccicheck" mentions
additional modes.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/coccinelle.txt?id=ec97946ed038f4b3faa587bc76152b198805b0c4#n170

They refer to specific output formats for the result from the
static source code analysis.

* How often would you like to look at proposed changes by the
  Org mode format (of Emacs)?
  http://orgmode.org/

* Do you find the report mode also useful occasionally?


Are you interested to get further output variants?

Examples:
* CSV
* XML

Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci