doc/Overview.txt

Aiaiai is a tool for validating Linux kernel patches using various
open-source projects.

Aiaiai customers are Linux kernel subsystem maintainers and developers.

Aiaiai usage scenarios include.

1. A Linux kernel developer has a patch or patch-set which he/she is
   going to submitting to the maintainer or the subsystem mailing list.
   The developer uses Aiaiai to validate the patch before sending it
   out.
2. A subsystem maintainer regularly receives patches from the developer
   community. The maintainer validates the patches before merging them
   into the subsystem kernel tree.
3. A group of developers work together on a kernel subsystem. Developers
   send their patches to the mailing list, where other group members
   review the patches, and eventually the maintainer applies the patches
   to the central git repository. The group uses Aiaiai for validating
   patches submitted to the mailing list. The Aiaiai e-mail front-end is
   used for dealing with the mailing list. It identifies patches and
   patch-sets, validates them, and sends validation results back to the
   submitter and (optionally) the mailing list.
4. Similarly, a group of developers works on a kernel subsystem, but
   uses gerrit for review. The group has a Jenkins server, which has the
   gerrit plugin installed. For every new patch in gerrit, or a new
   version of a patch, the plugin runs the Aiaiai gerrit front-end
   script, which validates the patch and stores the results in the
   gerrit comments for this patch.

Here is a brief description how Aiaiai validates patches.

1. Aiaiai builds the baseline, i.e., the kernel tree before the patches
   are applied. Aiaiai uses parallel builds.
2. Aiaiai applies the patches and builds the kernel tree again.
3. When doing steps 1 and 2, Aiaiai also uses the following open-source
   static analysis tools: sparse, smatch, cppcheck, and coccinelle (AKA
   spatch).
4. Aiaiai compares the 2 resulting build logs in a smart way (taking
   into account line number changes, etc)
5. In case of patch-sets, Aiaiai also runs the bisectability test,
   i.e., it applies the patches one-by-one and verifies that the kernel
   tree compiles a each step.
6. Aiaiai reports about all the new warnings from gcc, sparse, smatch,
   cppcheck, and coccinelle. Aiaiai also runs the 'checkpatch.pl' script
   for every patch of the patch-set and reports about all the warnings.
7. The report is either printed to the console, or sent to the submitter
   and/or the mailing list by e-mail, or stored in the gerrit as a
   review comment for the patch. This depends on whether the e-mail or
   gerrit front-ends are used or not.

Here is an example of Aiaiai report.

--------------------------------------------------------------------------------

1  Successfully built configuration "my_defconfig,i386", results:
2
3  --- before_patching.log
4  +++ after_patching.log
5  @@ @@
6  -drivers/staging/cruft/my_drv.c: In function ‘my_pool_destroy’:
7  -drivers/staging/cruft/my_drv.c:165:22: warning: variable ‘test1’ set but not used [-Wunused-but-set-variable]
8  @@ @@
9  +drivers/staging/cruft/my_drv.c: In function ‘my_event_handler’:
10 +drivers/staging/cruft/my_drv.c:311:36: warning: unused variable ‘reg’ [-Wunused-variable]
11 +drivers/staging/cruft/my_drv.c:1001:1-7: preceding lock on line 837 [coccinelle]
12 +drivers/staging/cruft/my_drv.c:834 my_int_data(12) warn: variable dereferenced before check 'priv' (see line 827) [smatch]

--------------------------------------------------------------------------------

o Line 1 says that configuration "my_defconfig" for architecture i386 has been
  built (so the patch-set compiles). If it didn't, Aiaiai would report
  about that.
o Starting from line 3 we have a diff of 2 build logs - before and after
  patching.
o Lines 6 and 7 tell that the patch-set eliminated a warning, which is very
  welcome.
o Lines 9 and 10 tell that the patch-set introduced a gcc warning, which is
  less welcome.
o Line 11 a complaint form coccinelle about locking. Worth looking closer.
  The coccinelle scripts that are part of the Linux kernel do not usually
  produce many false positives.
o Line 12 tells that smatch has a complaint.