Andrew Morton wrote:
> On Fri, 27 Feb 2009 17:59:06 -0800 Jeremy Fitzhardinge
>> This series implements the core parts of Xen dom0 support; that is, just
>> enough to get the kernel started when booted by Xen as a dom0 kernel.
> And what other patches can we expect to see to complete the xen dom0
There's a bit of a gradient. There's probably another 2-3 similarly
sized series to get everything so that you can boot dom0 out of the box
(core, apic, swiotlb/agp/drm, backend drivers, tools). And then a
scattering of smaller things which may or may not be upstreamable. The
vast majority of it is Xen-specific code, rather than changes to core
kernel. I'm in no particular rush to get it all into the kernel, but I
would like to get the core parts in for .30 so that its basically
useful, and the delta to feature-complete isn't very large (a big reason
is to keep the out-of-tree patch size down for distros).
> I hate to be the one to say it, but we should sit down and work out
> whether it is justifiable to merge any of this into Linux. I think
> it's still the case that the Xen technology is the "old" way and that
> the world is moving off in the "new" direction, KVM?
I don't think that's a particularly useful way to look at it. They're
different approaches to the problem, and have different tradeoffs.
The more important question is: are there real users for this stuff?
Does not merging it cause more net disadvantage than merging it?
Despite all the noise made about kvm in kernel circles, Xen has a large
and growing installed base. At the moment its all running on massive
out-of-tree patches, which doesn't make anyone happy. It's best that it
be in the mainline kernel. You know, like we argue for everything else.
> In three years time, will we regret having merged this?
Its a pretty minor amount of extra stuff on top of what's been added
over the last 3 years, so I don't think it's going to tip the scales on
its own. I wouldn't be comfortable in trying to merge something that's