The title says it all. The very last components that were needed to run Xen as a dom0 have finally reached kernel.org, during the last “feature merge window”. The Xen block backend was one major feature missing from 2.6.39 dom0 support, and it’s now included. Posts on the Xen blog, at Oracle and at Citrix celebrate this achievement.
In the past, upstreaming Xen features had been quite painful. A post from Linus itself on the MKML (Linux Kernel Mailing List) says it all:
The fact is (and this is a _fact_): Xen is a total mess from a development standpoint. I talked about this in private with Jeremy. 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.
Thomas pointed to patches that add _explicitly_ Xen-related special cases that aren’t even trying to make sense. See the local apic thing.
So quite frankly, I wish some of the Xen people looked themselves in the mirror, and then asked themselves “would _I_ merge something ugly like that, if it was filling my subsystem with totally unrelated hacks for some other crap”?
Seriously.
If it was just the local APIC, fine. But it may be just the local APIC code this time around, next time it will be something else. It’s been TLB, it’s been entry_*.S, it’s been all over. Some of them are performance issues.
I dunno. I just do know that I pointed out the statistics for how mindlessly incestuous the Xen patches have historically been to Jeremy. He admitted it. I’ve not seen _anybody_ say that things will improve.
Xen has been painful. If you give maintainers pain, don’t expect them to love you or respect you.
So I would really suggest that Xen people should look at _why_ they are giving maintainers so much pain.
Linus
Then, in an undetected reply to the news on slashdot, Jeremy itself explained what happened, and what changed to make the upstreaming of feature possible. VPS Hosting Pro understood what the “I” meant here: it really was Jeremy himself replying to a slashdotter:
What was really going on with that particular patch posting burst and the resulting, er, discussion was to try and draw some more developer attention, since – as you say – I really was operating solo at that point. Various companies had promised resources (ie people), but nothing was actually forthcoming. In the unlikely event that that particular patchset was accepted it would have been moot, but the real purpose was to highlight how much still needed to be done and to get people to publically express interest in getting dom0 into mainline, ideally backed by action/resources.
And while the feedback from the Linux community was strong and somewhat negative, it also put on record what form an acceptable upstreaming path would take.
The outcome was
- the Xen/dom0 ABI needed to be refined, since the original one required some pretty unpleasant kernel changes, and didn’t really make much sense
- I needed to come up with a new, much more incremental dom0 upstreaming strategy
For the second, I did this by making sure that each patch supporting dom0 functionality also had at least some other purpose (many to do with pv-hvm), so there wasn’t the perception of an endless stream of “not yet useful patches” (which is frowned upon). It ended up being so incremental that the “can boot as dom0″ milestone (2.6.37) came as a complete surprise even to people within the Xen community.
And of course, I got a big boost when Konrad from Oracle and Ian and Stefano from Citrix started contributing a significant amount of time to the dom0 effort, taking over responsibility for getting large chunks of functionality into upstreamable form. Their help really tipped it from being a endless slog into an achievable goal.