Zack's Kernel News
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.
« Previous 1 2 3
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Fedora Asahi 40 Remix Available for Macs with Apple Silicon
If you've been anticipating KDE's Plasma 6 for your Apple Silicon-powered Mac, then you're in luck.
-
Red Hat Adds New Deployment Option for Enterprise Linux Platforms
Red Hat has re-imagined enterprise Linux for an AI future with Image Mode.
-
OSJH and LPI Release 2024 Open Source Pros Job Survey Results
See what open source professionals look for in a new role.
-
Proton 9.0-1 Released to Improve Gaming with Steam
The latest release of Proton 9 adds several improvements and fixes an issue that has been problematic for Linux users.
-
So Long Neofetch and Thanks for the Info
Today is a day that every Linux user who enjoys bragging about their system(s) will mourn, as Neofetch has come to an end.
-
Ubuntu 24.04 Comes with a “Flaw"
If you're thinking you might want to upgrade from your current Ubuntu release to the latest, there's something you might want to consider before doing so.
-
Canonical Releases Ubuntu 24.04
After a brief pause because of the XZ vulnerability, Ubuntu 24.04 is now available for install.
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.