[Xen-devel] Re: Xen is a feature

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

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
> specifically.
>   
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.
   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel