Differences

This shows you the differences between two versions of the page.

--- coccicheck [2015/10/22 13:46]
Luis R. Rodriguez
+++ coccicheck [2016/06/24 09:08]
Nicolas Palix [Who runs these tests]
@@ Line 15: / Line 15: @@
 ==== Modes ====
-There are three different modes you can use to use the semantic patches:
+There are four different modes you can use to use the semantic patches:
-  * report - lets you generate a report - this is the '''default''' mode if one is not specified
-  * org - xxx
   * patch - lets you fix the issues found
+  * report - lets you generate a report - this is the '''default''' mode if one is not specified
+  * context - highlights lines of interest and their context in a diff-like style.Lines of interest are indicated with '-'.
+  * org - generates a report in the Org mode format of Emacs
-You specify the mode want to operate
+You specify the mode want to operate. Note that not all semantic patches implement all modes. For easy use
+of Coccinelle, the default mode is "report".
+Two other modes provide some common combinations of these modes.
+  * chain - tries the previous modes in the order above until one succeeds.
+  * rep+ctxt - runs successively the report mode and the context mode. It should be used with the C option (described later) which checks the code on a file basis.
 ==== Run tests ====
@@ Line 30: / Line 37: @@
 make coccicheck MODE=report
 </code>
+To produce patches for the entire kernel, run:
+<code bash>
+make coccicheck MODE=patch
+</code>
+For each semantic patch, a commit message is proposed.  It gives a description of the problem being checked by the semantic patch, and includes a reference to Coccinelle.
+As any static code analyzer, Coccinelle produces false positives. Thus, reports must be carefully checked, and patches reviewed.
+==== Maintainer work ====
 If you are a maintainer you may want to use M=your/maintained-path/ to limit the scope to only the files you maintain. For instance the following will generate a report for all files in drivers/net/ only.
@@ Line 42: / Line 61: @@
 <code bash>
-export COCCI=scripts/coccinelle/locks/double_lock.cocci
+make coccicheck COCCI=scripts/coccinelle/locks/double_lock.cocci MODE=report
-make coccicheck MODE=report
 </code>
-===== Types of tests ====
+or
+<code bash>
+make coccicheck COCCI=scripts/coccinelle/locks/double_lock.cocci MODE=patch
+</code>
+===== Controlling Which Files are Processed by Coccinelle =====
+By default the entire kernel source tree is checked. To apply Coccinelle to a specific directory, M= can be used. For example, to check drivers/net/wireless/ one may write:
+<code bash>
+make coccicheck MODE=report M=drivers/net/wireless/
+</code>
+To apply Coccinelle on a file basis, instead of a directory basis, the following command may be used:
+<code bash>
+make C=1 CHECK="scripts/coccicheck"
+</code>
+To check only newly edited code, use the value 2 for the C flag, i.e.
+<code bash>
+make C=2 CHECK="scripts/coccicheck"
+</code>
+In these modes, which works on a file basis, there is no information about semantic patches displayed, and no commit message proposed.
+This runs every semantic patch in scripts/coccinelle by default. The COCCI variable may additionally be used to only apply a single semantic patch as shown in the previous section.
+The "report" mode is the default. You can select another one with the MODE variable explained above.
+===== Additional flags =====
+Additional flags can be passed to spatch through the SPFLAGS variable.
+<code bash>
+make SPFLAGS=--use-idutils coccicheck
+</code>
+See spatch --help to learn more about spatch options.
+===== Proposing new semantic patches ======
+New semantic patches can be proposed and submitted by kernel developers. For sake of clarity, they should be organized in the sub-directories of 'scripts/coccinelle/'.
+===== Types of tests =====
 Below we document each type of test category which as been devised.
@@ Line 92: / Line 156: @@
 ===== Who runs these tests =====
-Linux kernel maintainers are encouraged to make use of the cocciecheck to vet for issues on their tree. This can be used to help review quality of patches before they get merged into your tree as well.
+Linux kernel maintainers are encouraged to make use of the coccicheck to vet for issues on their tree. This can be used to help review quality of patches before they get merged into your tree as well.
-These days coccicheck is run every now and then by Julia Lawall, false possitives are reviewed (in particular cocci files where confidence is annotated as low), and then once issues are confirmed patches typically are sent to maintainers.
+These days coccicheck is run every now and then by Julia Lawall, false positives are reviewed (in particular cocci files where confidence is annotated as low), and then once issues are confirmed patches typically are sent to maintainers.
-Average developers can and should use coccicheck as well but care should be taken to ensure the '''Confidence''' tag is reviewed and proper dilligence is done before sending any reports / fixes to kernel maintainers.
+Average developers can and should use coccicheck as well but care should be taken to ensure the '''Confidence''' tag is reviewed and proper diligence is done before sending any reports / fixes to kernel maintainers.
 It seems the zero day bot test infrastructure also makes use of 'make coccicheck' --- this section needs to be extended to document in what capacity this is done, how often, etc.

Wiki

User Tools

Site Tools

Differences

Page Tools