Kernel Summit

Two weeks back was the Linux Kernel Developers Summit. The Kernel Summit is a two day, developer-to-developer, invite-only conference where the kernel hackers sit down and talk about our feelings. It is not, unfortunately, a hack fest. Instead, the big arguments too heated or otherwise involved for the mailing lists are discussed. An attempt is made to reach consensus on the future direction of the kernel. A cabal at its best.

For whatever reason, I failed to blog the conference from the conference. To make reparations, here and now I will go over some of my thoughts.

Monday started pretty slowly. It was fairly clear, right off the bat, that this conference would mirror last year - little contention and lots of agreement. Compared to the summit two and three years ago, the lack of violent disagreement is always surprising. It certainly drives home the point about the state of kernel development. We started off with a processor panel, which was pretty neat. Both Intel and AMD provided us with honest-to-god new information and not a marketing spiel. We moved on to virtual memory, software suspend, kobjects, and then video drivers. For that session, the always charming Keith Packard stopped by to give us an overview of the current world of graphics hardware and the current situation with video drivers. We discussed where to go from there. I told him to be really harsh on us. I do not think he was harsh enough, but he definitely got across the point that the current DRI-fb-X menage a trois is not the way to go.

Following Keith's session, I chaired a session on improving desktop performance from the kernel's point of view. Issues such as boot time, interactivity, desktop-optimized I/O schedulers, and a reduction in the need for polling were discussed. Linus pointed out that he traced some desktop application and it made 30,000 system calls, touching thousands of files, in the initial seconds of start up. Clearly, he noted, the onus lies more so on these applications than the kernel for improvement.

Tuesday found a customer panel and topics on clustered storage, kexec, RAS, networking, asynchronous I/O, multipath I/O, virtualization, security, CKRM, and OSDL. Much of it was yawn material.

Kernel Summit Group Photo

The final session raised some contention. As Slashdot and other fine news reporting agencies have noted, we have decided to delay the release of 2.7. Yes, delay, not cancel. I have never been a huge fan of the kernel development process - especially after working on GNOME - but I am cautiously interested in this new direction for 2.6. Especially since it really is not a new direction. We are, in fact, ready to and capable of forking 2.6 and starting 2.7. But 2.6 is mature, stable, and we are all generally very happy with it. We also do not have any huge stability-crushing baby-killing changes queued up. Instead, we have a lot of incremental changes, new features, and such. We have been able to slip a lot of these into 2.6, in fact -- we merged 4K stacks, huge scheduler behavior changes, and object-based reverse mapping in post 2.6! A solid 10MB of patches a month have found their way into 2.6. Yet stability has not suffered. 2.6 is better off than any previous kernel, and the dynamic duo of Linus and Andrew is really working. Progress is fast, features are merged, yet stability remains. The question we asked, then, is why change that?

The answer, as noted and second guessed and complained about, is that there is no reason to. As long as we can sustain it, we will continue to use Andrew's 2.6-mm tree as a staging ground for new patches. Linus will continue to work on 2.6. 2.6 will remain a stable kernel, yet from time-to-time see more adventurous (but still well-tested) patches. This is the stuff that vendors ship, anyhow. Ultimately, if the size or stability of 2.6-mm ever becomes unwieldy, we can then fork 2.7. In the meantime, 2.6 can remain stable (in both the code sense and the user-space API/ABI sense) yet address the too-long-release-cycle problem.

The only risk is a loss of time on the kernel developer's part. If we realize that this method is unsustainable in the face of stability, we will merely end up branching 2.7 later rather than earlier. I have faith that it will work, however. The combination of Andrew and Linus working together is gold. Andrew's patch scripts let him manage everything on a per-patch basis, and he can easily maintain a tree of patches against 2.6 proper. Linus's use of BitKeeper, on the other hand, allows him to easily pull from the trees of maintainers. Also, Andrew just rocks.

All in all, the kernel summit was a lovely opportunity to get together and see friends I see much too infrequently -- especially Pat, Greg, Zwane, Chris, Rusty, and Andrew. Some good decisions came out of it, but the most important is the very clear notion that the kernel is mature in terms of features and that innovation lies elsewhere. Which is fine with me.