Ingo Molnar wrote:
> * Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>
>
>>> My suggestion would be for Linux to make only a /single/ external
>>> ABI promise: VMI. (and we can extend it with higher-level paravirt
>>> ops, etc.)
>>>
>> "VMI" is not a promise, it's just three letters. It doesn't even mean
>> the same thing now as it did 12 months ago. Turning "VMI" from three
>> letters into anything remotely like a promise is a huge amount of work
>> which requires:
>>
>> 1. someone actually sit down and fully document what all those
>> entrypoints are going to do
>> 2. everyone to implement them
>> 3. someone to test that all the implementations conform to the
>> document (bearing in mind that if anyone is going to go to all
>> this effort, they're going to use this with non-Linux guests)
>> 4. and repeat all that every subsequent update
>>
>
> There's no process needed. The only thing needed is to treat the Linux
> implementation as the reference design, documentation and specification.
>
What Linux implementation? Linux as a client of this interface? So
everyone implements as much of the ABI as needed to get Linux to boot?
We have an excellent example of how well that model works. Thousands of
BIOS implementations all implementing just enough of the various BIOS
interfaces to get Windows to boot. And then all fall over as soon as
you try to be non-Windows, or even a later version of Windows. It's the
path to being absolutely inundated with legacy crap.
You're arguing that we should have a single hypervisor ABI in order to,
among other things, reduce the test matrix, and yet the ABI is entirely
defined by testing to see how well a given implementation runs some
random version of Linux. And if Linux wants to use that interface in a
different way, everyone is supposed to magically keep up.
And all this is supposed to be managed by multiple disparate independent
out-of-tree implementations?
Yep, I want a pony too.
> Treat it as we treat the Linux system calls. We promise not to change
> them.
OK. How does that help with "not hindering Linux's development"?
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxx
https://lists.osdl.org/mailman/listinfo/virtualization
