[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: Xen is a feature

Theodore Tso wrote:
The other argument is that by merging Xen into Linux, it becomes
easier for kernel developers to understand *why* "if (xen) ..." shows
up in random places in core kernel code, and it becomes easier to
clean that up.

I explicitly put the "if (xen) ..." stuff in there because I *know* its ugly: I didn't want to sugar-coat it and I didn't want to hide it behind some bogus prettifying abstraction layer, and I didn't want it to be left unfixed.

But it was also the pragmatic way to make progress towards something which actually works and is actually useful to people.

If Xen isn't merged, it becomes much harder to believe that those
cleanups will occur, since the Xen developers might stonewall such
cleanups for reasons that Linux developers might not consider valid.
So the threshold for accepting patches might be much higher, since the
subsystem maintainers involved might decide to NAK patches as
uglifying the Linux kernel codebase with no real benefit to the Linux
codebase --- and not much hope that said ugly hacks will get cleaned
up later.  Historically, once code with warts gets merged, we lose all
leverage towards fixing those warts afterwards; this is true in
general, and not a statement of a lack of trust of Xen developers

Well, my whole goal with getting Xen into the kernel has been to make it a proper first-class kernel subsystem. That is: merge it with full review and consensus; take comments and bug reports seriously; work with other subsystem maintainers to sort problems out; take advantage of better kernel mechanisms to improve the Xen code; add better kernel mechanisms to improve the rest of the kernel.

Stonewalling or blocking changes don't come into it. But it works two ways; If I feel that I'm being stonewalled, if people aren't working with me, then I get frustrated.

This doesn't make merging Xen *impossible*, but probably makes it
harder, since each of those objections will have to be cleared,
possibly by refactoring the code so that it adds benefits not just for
Xen, but some other in-kernel user of that abstraction (i.e., like
KVM, lguest, etc.) or by cleaning up the code in general, in order to
clear NAK's by the relevant developers.

A lot of my kernel work of the last few years has been along those lines: lots of unification, refactoring, cleanups, horse-trading with other subsystems to find common ground, etc. As a result, most of the Xen stuff has slipped in fairly cleanly and quietly.

Consequently, very few people seem to realize how uncontroversial the Xen work has been so far; in the 3ish years I've been working on it, this is the first big mailing list blowup. In the meantime, there have been lots of users happily using Xen as shipped with their stock kernel.

If Xen is merged, then ultimately Linus gets to make the call about
whether something gets fixed, even at the cost of making a change to
the hypervisor/dom0 interface.  So this would likely decrease the
threshold of what has to be fixed before people are willing to ACK a
Xen merge, since there's better confidence that these warts will be
cleaned up.

Well, lets be precise here. Full Xen domU support has been in released kernels for something like 18 months now. This whole discussion isn't about "should we merge Xen?", because that has already happened. A groups of distinct subsystem developers got together, worked out a common set of requirements, built an interface to meet those requirements and implemented it. The result is Xen, VMI, lguest - and now kvm, which didn't exist at the time, but has since found the interface useful.

This controversy is about the - quite small - dom0 support subset of Xen, which primarily relates to allowing Xen domains to have direct access to hardware. It is technically challenging because it covers quite different set of functionality in different parts of the kernel - pci, dma, interrupts, etc.

In some cases, the dom0 changes are fairly uncontroversial because they're just another user of existing interfaces (dma_ops) or slightly controversial because they need tweaks to an existing interface (swiotlb).

However, where the existing kernel code doesn't have a suitable abstraction layer, or even particularly clean internal interfaces (like the apic code), working out how to make the appropriate Xen changes poses a tricky tradeoff: do I attempt to restructure a large complex subsystem with lots of subtle interactions with the rest of the kernel - not to mention subtle interactions with many types of quirky hardware - just to add my changes? Or do I make some relatively small, low risk (but low beauty) changes to get the job done?

I went for the latter; the cost-benefit tradeoff just didn't seem to justify a massive refactor. But others have pretty pointedly had the opposite view, so I'm now investigating what its actually going to involve.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.