i think the main problem with Sparse isnt even technical but just a few
minor gotchas IMO that artificially work against the widespread use of
Sparse in various common workflows.
Sparse is a cool tool that extends upon C types (and more), but it's
been made too hard to use widely:
- right now it's opt-in with no ability for testers to use it
transparently while also building the kernel. Forcing a second
kernel build just for 'debugging' reduces the userbase.
- it produces way too much output for people to act upon and see any
real "improvement" in the end result. (Obviously this is partly a
side-effect of its shallow use.) Producing too much output by default
reduces the userbase further.
- delta analysis (watching what new Sparse warnings pop up) is
possible, Al Viro has the "remapper" tool:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/remapper.git/
but forcing delta analysis as the only viable Sparse use poses yet
another barrier against use and does not allow state-less,
single-pass test feedback.
There are simpler tools (like for example checkpatch.pl) which are much
cruder in many aspects, but still they are used much more because they
do not have such basic usage problems. The artificial limitations on
Sparse usage keep it from being the tool it could be, IMO.
A tool that has quality assurance effects _must_ be actionable by a
broad developer base and needs to be no-hassle enabled by testers -
otherwise it will just drown in sheer entropy.
Fortunately these problems are all solvable gradually:
- a kbuild mechanism to get _parallel_ Sparse checks. I.e. both the
real .o gets produced but also the "make C=1" output is produced.
Testers would be enabled to do Sparse checks "alongside" of a normal
kernel build. (Sparse is plenty fast for this to be practical)
- kbuild mechanism with which subsystem maintainers could mark specific
files (or all of their subdirectories) of their subsystem as to be
Sparse-checked by default. [if a .config debug option is enabled]
For example we'd mark all of arch/x86/*.o and kernel/sched*.o in such
a way for example.
- a second layer would be very useful as well: failures would turn into
build failures if a debug .config switch is enabled.
this (and i'm sure some other, simple measures) would push Sparse into
the mainstream and it would allow us to integrate it into existing
practices of automated testing.
if we did all that Sparse might even turn into the native, built-in
Linux kernel compiler of the future: it already has the hardest bit
implemented as it can parse the kernel source and generates syntax trees
from it, generating a real .o from it is just one next step.
On a similar note, it would be nice if subsystem maintainers had a
kbuild mechanism to have the fails they maintain to be built via -Werr
(if an opt-in .config option is enabled).
I'd enforce it in a heartbeat on all files i'm involved with - but i
cannot enforce it on the more than 10,000 files the kernel has. Grepping
the warnings of files i'm interested is not possible reliably from make
-j builds.
So if someone wants me to try a kbuild patch to that end, i'd love to
give it a shot :-)
Ingo
--
