So what's your argument here? That if Xen/ESX/whatever are evolved
separately from Linux, then they should be tied together behind one ABI,
so that even if one could support a new Linux feature it can't move
until everyone else implementing the ABI too? How does that help anyone?
The big practical difficulty is that there are no examples of an ABI
with multiple implementations all being sufficiently cross-compatible
that a user of that ABI can actually rely on it working consistently
(and certainly not to the extent that it actually reduces the test
matrix size). There are masses of subtle details that are hard to get
right, and making sure that multiple implementations get all this right
is apparently impossible (otherwise ACPI would be a dream to work with...).
lguest is special, because it is purely kernel-internal (and because
Rusty wrote it, of course). kvm is not, and I don't see why you think
it is. In its simplest form its a thin layer which exposes hardware
virtualization to usermode, which happens to be qemu at the moment. Its
evolving some bells and whistles, but at heart it's being developed by a
company with just as much commercial interest and backing as Xen and
VMI, and it has the scope to be just as cross-platform.
Sure there is. It needs the usermode part to keep sync; that's easy if
its qemu, but you're stuck if its a proprietary usermode implementing
that end of the kvm equation.
Well, if the kernel goes one way and Xen doesn't follow, then that
pretty severely restricts Xen's usefulness - there's a pretty strong
incentive for Xen to keep supporting Linux. And besides, Xen is all
GPL, so anyone who's sufficiently motivated can do this work.
Well, that's the reason for minimizing Linux's exposure to any ABI.
Clearly the interface to a hypervisor has to be *some* ABI. But it
doesn't help anyone if there's an extra uber-ABI which is a superset of
all the underlying hypervisor ABIs; that's just a big rigid, brittle mess.
The whole point of pv_ops is to allow the hypervisors interfaces to
evolve at their own pace without having to constrain the core kernel's
development
Well, if there were any other guests that used VMI that might be
useful. You'd get further using the Xen ABI.
J
-
