Proposals for Kernel Summit discussions

As preparation for this year's Kernel Summit gets underway, a new "more transparent" process is being used to select the 80-100 participants. The Summit will take place August 27-29, just prior to LinuxCon North America in San Diego. Those interested in attending are being asked to describe the technical expertise they will bring to the meeting, as well as to suggest topics for discussion. All of that is taking place on the ksummit-2012-discuss mailing list since the announcement on June 14, so it seems worth a look to see what kinds of topics may find their way onto the agenda.

Development process issues are a fairly common topic at the summit and they figure in a number of the suggestions for this year. One of the hot topics is the role of maintainers with multiple, at least partly related, ideas about discussions in that area. Thomas Gleixner noted a few concerns that he had in a mini-rant:

As one might guess, that kicked off a bit of a conversation about those problems on the list, but also led several developers to concur about the need to discuss the problems at the summit. Somewhat more diplomatically, Trond Myklebust suggested a related discussion on a possible restructuring of the maintainer's role:

Greg Kroah-Hartman also wants to talk about maintainership and offered to "referee" a discussion. He has some ideas that he described at LinuxCon Japan and in a recent linux-kernel posting that he thinks "will go a long ways in helping smooth this out". John Linville also expressed interest in that kind of discussion.

Another area that is generating a lot of interest is the stable tree. Kroah-Hartman is interested in finding out how the process is working for the other kernel developers:

Based on the number of other submissions that mentioned the stable tree, there seems to be a fair amount to discuss. The relationship between the stable tree and the distributions is one fertile area. Kroah-Hartman said that he often has to go "digging through distro kernel trees" to find patches to apply, to which Andrew Morton suggested that the "distro people need a vigorous wedgie" for not making that easier. Various distribution kernel maintainers (e.g. Josh Boyer and Jiri Kosina) agreed that the distributions could do better, but that some discussion of the process would be worthwhile.

In addition, some discussion of how distributions could better work with the upstream kernel for regression tracking and bug reporting was proposed by Boyer. Kosina wants to discuss the stable review process with an eye toward helping distributions decide which patches to merge into their kernels. Mark Brown is also interested but from the perspective of embedded rather than enterprise distributions. Others also expressed interest in having stable/longterm tree discussions.

How to track bugs and regressions was a topic proposed by Rafael Wysocki, who has been reporting to the summit on that topic for many years. He was joined by Dave Jones, who would like to report on bugs and regressions, both those found by his "trinity" stress-testing tool and ones that have been found in the Fedora kernel over the last year. Like Wysocki, Kosina is also interested in discussing whether the kernel bugzilla is the right tool for tracking bugs and regressions.

Kernel testing is another area that seems ripe for a discussion. Fengguang Wu would like to report on his efforts to test kernels as each new commit is added:

Wu's posting spawned a long thread where various developers described their test setups and what could be done better. Jones mentioned the Coverity scanner in that thread, which led Jason Wessel to highlight Jones's comment as well as give more information on the tool and the kinds of information it can provide. More and better automated kernel testing is definitely on the minds of a lot of potential summit attendees.

James Bottomley would like to eliminate "kernel work creation schemes", in particular he targeted the amount of code that is needed to support CONFIG_HOTPLUG:

There were few defenders of CONFIG_HOTPLUG=n in the thread, but he was also interested in finding ways to avoid constructs that lead to a lot of code churn to no good end. In a somewhat similar vein, H. Peter Anvin would like to discuss the baseline requirements for the kernel. Supporting some of the niche uses of Linux (on exotic hardware or with seriously outdated toolchains) creates an ongoing cost for kernel hackers that Anvin would like to see reduced or eliminated.

Several PCI topics were proposed, including PCI root bus hotplug issues by Yinghai Lu and a PCI breakout session that Benjamin Herrenschmidt suggested. In the latter, Lu's work, some PCI-related KVM issues, cleaning up some PowerPC special cases, and the rework of the PCI hotplug core could all be discussed. As Herrenschmidt put it: "I think there's enough material to keep us busy and a face to face round table with a white board might end up being just the right thing to do".

Memory management topics also seem popular. Glauber Costa proposed several topics, including kmem tracking and per-memory-control-group kmem memory shrinking, while Hiroyuki Kamezawa suggested memory control group topics. Johannes Weiner is also interested in talking about a separate memory management tree that would supplement the work that Morton does with the -mm tree. The ever-popular memory control group writeback topic was also suggested by Wu and Weiner.

Srivatsa S. Bhat would like to present a newcomer's perspective on kernel development with an eye toward reducing some of the challenges new developers face. Josef Bacik has a similar idea, and would like to discuss how to make it easier for new contributors. In addition to a report on work in the USB subsystem (and USB 3.0 in particular), Sarah Sharp would like to "do a brief readout" about what she learns at AdaCamp in July:

As one can see, these proposals (and many more that were not mentioned) range all over the kernel map. There tends to be a focus on more process and social aspects of the kernel at the summit, mostly because the hardcore technical topics are generally better handled by a more focused group. The summit tries to address global concerns, and there seem to be plenty to choose from.