Messages in this thread | | | Date | Wed, 25 Jun 2008 16:53:31 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 4/5 v2] x86 boot: show pfn addresses in hex not decimal in some kernel info printks |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> The format warnings are too useful to drop entirely. I guess sparse > could be taught to do them, and then we could drop the gcc support for > them. But that would still limit coverage a _lot_.
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
| |