Kernel Podcasting

Jon Masters has set up kernelpodcast.org with a semi-daily summary of events in the kernel development world in the form of podcasts and audio transcripts. We wish him the best of luck with it – it sounds like a great project!

Status of Xen

Incorporating the Xen virtualization patches into the official kernel tree has garnered a lot of interest. Xen lets users create multiple virtual computers on a single piece of hardware, which is useful for getting close to 100 percent utilization out of a given system (e.g., in a server farm). The prospect of one day getting Xen into the official sources is enough to set the toes of Xen developers everywhere a-dancing in their socks.

Recently Ingo Molnar suggested that this step might be a good idea, and, not surprisingly, a number of folks voiced support and began discussing which of Xen's sprawling elements to include or exclude in an initial patch set. Theodore Ts'o also approved of the idea, and Steven Rostedt compared the whole situation to Xen folks asking for an apple and getting apple pie instead.

Some people also voice their opposition. Alan Cox said, "Start by changing the mentality. Right now much of the patched code looks like 'We made a decision years ago when creating Xen. Now we need to force that code we wrote into Linux somehow'." He suggested that merging Xen was less important than creating the appropriate framework in Linux to support Xen. He also restated this, saying he felt Xen's implementation might just be wrong. He suggested "turning off" Xen features to get a minimal implementation that could be architected properly and merged into the kernel with minimal problems, then more stuff could be added over time.

Part of the problem, as Theodore pointed out, is that accepting a poor design into the kernel would make it very difficult to fix later because users must continue to be supported in future kernels. A bad decision in the early days of a Xen merge could make various regions of the kernel harder to maintain or debug for a long time into the future.

Various Xen advocates argued against some of these suggestions. George Dunlap pointed out that such a fundamental reimplementation, along with dropping so many of Xen's existing, working features, would essentially mean starting an entirely new project – which would be quite different from Xen – from scratch.

Theodore and others started offering suggestions of how the project might work and how merging Xen as-is might ultimately end up being much more costly. But the Xen folks seemed to be getting more and more frustrated with that line of thinking. Ultimately, Linus Torvalds joined the discussion, saying, "You're totally missing the problem. If Xen was a single driver thing, we wouldn't have this discussion. But as is, Xen craps all over OTHER PEOPLE'S CODE. When those people then aren't interested in Xen, why is anybody surprised that people aren't excited?" And elsewhere (in a different thread) he added, "Xen pollutes the architecture code in ways that NO OTHER subsystem does. And I have never EVER seen the Xen developers really acknowledge that and try to fix it."

So on the one hand, there are plenty of developers, users, and businesses who'd love to see Xen in the kernel, not just eventually, but right now. And on the other hand, the Xen codebase apparently makes very invasive, unwelcome changes all over the kernel, in addition to implementing interfaces that might cause long-term maintenance and support issues in future versions of Linux. Given all that, my guess is that the kernel folks will continue to refuse to accept Xen in its current form and that the Xen folks will have to figure out – probably with some pain – exactly where the compromise point will be. Probably discarding all of their hard-earned features would not be necessary, but certainly some parts of Xen would have to be reconceived.

At the same time, it also seems clear that a number of top kernel developers, including Alan Cox, are friendly to Xen and would be eager to help clarify what exactly would be acceptable for the Xen folks to submit into the kernel. It could be some time, perhaps months or years, before the controversy and bitterness resolves itself into a true cooperative effort. The recent discussion, for example, was more of a flame war (with the kernel folks on the more peaceful side) than a technical consideration of what to do.