The final session on the first day of the 2010 Kernel Summit was dedicated
to five-minute talks on specific topics. Some developers seemed to find it
one of the more productive sessions of the entire day.
Julia Lawall started off with a description of Coccinelle; that, in turn, started with a look
at bugs in the kernel code base. Using Coccinelle to find bugs in the
kernel showed that, over the last few years, the number of bugs which can
be identified by this tool has
remained roughly constant. The size of the kernel has grown considerably,
though, leading to the conclusion that the quality of the code as a whole
is improving. The bug density is going down in most subsystems; the
staging tree was notable for having a higher-than-usual number of bugs,
Coccinelle is useful for finding a lot of types of bugs through advanced
code analysis and pattern matching. It can finger many types of memory
leaks, locking problems, bad API usage, null pointer dereferences, and so
on. Arnd Bergmann noted that it can be very useful for refactoring as
well; he found it to be helpful in his big kernel lock removal work.
Andrew Morton suggested that some value could be gained by looking more
closely at fixes being merged into the mainline. Many of them could reveal
common bug patterns which would be amenable to detection with Coccinelle.
Evidently that kind of work is being done now. Rafael Wysocki said that
the kernel bugzilla tends to contain detailed information on bugs, their
source, and their resolution. Patches to the stable tree were also pointed
out as being a good source of information on bugs.
The talk concluded with a loud round of applause for this work.
Grant Likely talked about the use of the kernel's device model and its
limitations, which are becoming increasingly evident. A lot of code is not
using the information on device topology which is there now, and it is
proving increasingly difficult to make the device model work with new
code. Current hardware tends to have all kinds of complex
interrelationships which cannot really be represented in the device model's
simple hierarchy. So, Grant asked, is it time to review the device model?
Further discussion was deferred to the power management and embedded
microconfs to be held at the Linux Plumbers Conference later in the week.
Arnd Bergmann got up to ask: what should be done about the small number of
big kernel lock users remaining in the kernel? Should they be moved to the
staging tree? Linus said that he intends to set the default for
CONFIG_BKL in 2.6.37 to "no." The biggest remaining subsystem
with BKL problems, it seems, is Video4Linux; a patch exists and could
conceivably even be merged for 2.6.37. The other potential issue is the
UDF filesystem; distributors will be unwilling to do without UDF, so the
BKL will have to remain until it's fixed. Once that's taken care of,
though, the way seems clear for moving any other BKL-using code to the
staging tree. If it's not fixed within a few development cycles, that code
will then be staged out of the mainline entirely.
Thomas Gleixner talked briefly about his ongoing rework of the low-level
interrupt handling infrastructure. He is just about done with the
long-term project of removing do_IRQ() from the core. Most of the
architectures have already been fixed to not need it. There is a new set
of callbacks for interrupt controller chips; Thomas does not intend to
preserve the old callbacks past 2.6.38. There is a lot more work to be
done for this change, especially in the ARM tree where every CPU variant
has its own controller. Much of that work can be done with Coccinelle,
David Woodhouse concluded the session with a brief talk on the firmware
tree. Are there any distributions which are still shipping any firmware
from the kernel tree, as opposed to the separate firmware tree? Steven
Hemminger said that Vyatta still ships in-tree firmware; for a number of
network drivers, it tends to be more current than what is found in the
David would like to remove the remaining in-kernel firmware entirely; among
other things, that will force vendors to update firmware in the firmware
tree instead. Linus is amenable to that change, as long as the firmware
tree's code is at least as current as what's found in the kernel. He said
that he's happy to remove code, especially when it's politically sensitive
code. So it seems likely that, quite soon, there will be no more firmware
blobs in the kernel proper.
Next: Linux at NASDAQ (day 2).
to post comments)