Support needed to continue Smatch work

I have been doing Smatch static analysis work at Linaro under a larger
umbrella project to do with Linux kernel quality but unfortunately that
project has ended so I will be wrapping up at the end of the year unless
we can raise new support.

Smatch is an important tool for kernel development so hopefully there
are enough companies willing to support it financially and I will be
able to continue.  In fact, there potentially is an opportunity to
expand if companies with other large C projects and want static
analysis.  This isn't something we have explored very deeply but reach
out if you want to have that discussion.  Please contact
Bill Fletcher <[email protected]> for any inquiries, either
about supporting Smatch in the Linux kernel or about other static
analysis projects.

Background:  I am the author of the Smatch static checker.
https://github.com/error27/smatch

In the kernel we use a number of different static analysis tools with
different features and goals.  What makes Smatch unique is the flow
analysis.  Flow analysis is basically the logic of saying that if X is
true that must mean Y is true.  Smatch is the only Open Source static
checker with this level of flow analysis and the only one that does
analysis across function boundaries.  Being Open Source is important
because it lets you write project specific checks.  There are a number
of commercial static analysis tools that exist as well, however, for
parsing kernel code nothing else is at the same level.

This is borne out in the numbers.  I have been working on Smatch since
2010, first at Oracle and now at Linaro.  Over that period I have been
the number 12 bug fixer with 5568 patches and the number 2 bug reporter
with 2587 bug reports and almost all those fixes are driven by Smatch.
Smatch is included in several subsystem CI tools, such as Media and
Wireless and many maintainers use Smatch as well.

I like to say that static analysis is not just a product, it is an
on-going process.  I regularly review CVEs to consider how these bugs
could have been caught earlier with static analysis.  Also the kernel is
constantly changing and adding new APIs.  Without continuous updates
then a static checker will eventually bit rot.

An important part of what I do is review static checker warnings and
filter out the false positives.  People complain about false positives
but in some ways, with static analysis the false positive ratio is a
knob you can adjust where you can either have very few false positives
and miss bugs or you can have more false positives and catch more bugs.
Since the kernel is very important I prefer to have more false
positives and then manually review them.  This lets us catch as many
bugs as possible without annoying the developers.

Especially for cross function bugs, you need a human to figure out who
the correct developer is to handle an issue.  I've also found that
adding a bit of explanation to each bug report helps developers know
how to handle them faster.

To be honest, the work with Smatch will need to continue either way
because it's really important but it would be great if I could be a part
of that.  I still have a lot of plans for changes and improvements that
should be made.  I'm hoping there are several companies who could
support this project by paying a proportion of my salary.  This is
something that Linaro has done before with other shared cost projects.

I'll post again closer to the end of the year to let people know what's
happening next.