There is an increasing trend toward the use of "minisummits" for the
detailed discussion of issues specific to a kernel subsystem. Kernel
summits typically include a slot where the results from these sessions can
be reported back to the group as a whole. The results from three such
events were discussed at the 2008 kernel summit.
Len Brown went over the power management summit held last July in Ottawa;
some notes from that
gathering were posted here in August. The talk started with a quick
recap of recent events in the power management area; these include the
mainstream adoption of the tickless kernel, the establishment of lesswatts.org, and the creation of acpica.org, which, among other things,
contains public bugzilla and git servers for the ACPI reference
The number of unresolved bugs in the ACPI subsystem is dropping; it was 222
in 2004, but is 59 now (though one should count the 45 bugs which have been
pushed out to a separate suspend/resume category). New bugs continue to
come in at a steady rate, but the ACPI developers have been working at
addressing them and simultaneously taking care of the backlog. Most of the
bugs, Len notes, are problems which have always been present in the code;
very few of them are regressions being added by current work. Andi Kleen
(who was the ACPI maintainer while Len took a short sabbatical) made the
claim that ACPI is the only kernel subsystem which knows how many bugs it
There was some talk of the TI OMAP/ARM architecture which, after some
effort, is now running entirely on current kernel releases. The flow of
patches back upstream is still small, though, in need of improvement. Even
suspend and resume work for this architecture, but they are too slow for
USB autosuspend was mentioned briefly. It works, except for the systems
which it breaks completely. As a result, it is currently disabled by
default. That, says Len, is an unfortunate situation; disabled-by-default
code, in many cases, might as well have never been written.
John Linville summarized the wireless networking summit, also held in
Ottawa. One topic of interest is the cfg80211 API, a wireless
configuration interface which is intended to replace the much-maligned
wireless extensions interface. One idea being considered is to use DBus to
carry cfg80211 messages, which currently travel via netlink. That change
would require putting a DBus implementation into the kernel itself, which,
says John, might not be quite as crazy as it sounds.
The wireless regulatory
framework was covered briefly.
Power management is an issue for wireless networking as well. The wireless
protocols allow a device to announce its intention to go to sleep for a
while; the access point will then buffer packets until the interface wakes
up again. Linux needs support for this feature, as well as for some more
basic things. The mac80211 layer, for example, still lacks support for
suspend and resume.
Vendor support is getting better, especially with Atheros hiring a
community developer and beginning to contribute to the ath9k driver (though
not, yet, to the older ath5k driver). Broadcom, on the other hand, remains
as uncooperative as ever.
There will be another wireless networking summit held in the next year,
almost certainly in Europe.
The final topic of the session was containers. Several developers in this
area got together to talk about outstanding issues. Namespaces in general
were dealt with quickly; there are no real changes planned in this area.
On the other hand, the group decided to shift the checkpoint/restart
functionality over to a "one big syscall" approach; that work has since
been covered in this
article. The checkpoint developers are still working on getting a
simple case - checkpointing a single process with no outstanding signals or
other complicated situations - working before dealing with the more complex
The biggest area of interest would appear to be in resource management -
the general task of keeping containers within a set of resource usage
boundaries. The biggest problems in this area appear to be in the control
group interface. The current interface does not offer any sort of
transactional semantics, and it is hard for user-space administrative
processes to learn about resource-oriented events. Some of these problems
may be addressed via a new FIFO attached to each control group.
There is a lot of work going into I/O bandwidth controllers. Too much
work, in fact; there are four independent implementations circulating and
they do not appear to be converging. Some sort of consensus on the way
forward will need to be reached, but it is not, yet, clear what that
consensus will be. Other work in progress includes a swap controller
(which will be merged with the memory controller), the beginning of a
network traffic controller, and some early effort toward a user-space
library for working with control groups.
A member of the group asked whether the memory controller still requires
the addition of a pointer to the page structure. The kernel keeps
a page structure for every page of memory; there are a lot of
these structures, so struct page may be the most ruthlessly
compressed data structures in the system. Adding a new pointer is not a
price that the developers will willingly pay. Balbir Singh replied that
this pointer is still there for now, but there is a patch which removes
it. The problem is that this patch comes with a 4% performance loss; work
toward lessening that impact continues.
to post comments)