Re: Xen & VMI?

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Xen & VMI?
    ... which is the name we chose. ... What matters is the /ABI/ that the hypervisor uses to talk to a Linux ... In the VMWare/ESX case that's VMI. ... hypercall page call-table ABI or the legacy int $0x82 ABI. ...
    (Linux-Kernel)
  • Re: How Common Lisp sucks
    ... Except that Linux has a process for managing change, ... SBCL, CLISP, Allegro, etc. are implementations of Common Lisp. ... The POSIX standard is analogous to the hyperspec. ... the Posix community has processes for developing and evolving ...
    (comp.lang.lisp)
  • RE: C++ lib compatibility between Red Hat 9 and 7.3
    ... What he's wanting is a standard C++ ABI. ... same Mathematica binaries run on pretty much every Linux out there. ... >> all of your apps and they neither compile and definitely won't run. ...
    (RedHat)
  • Re: How Common Lisp sucks
    ... Except that Linux has a process for managing change, ... SBCL, CLISP, Allegro, etc. are implementations of Common Lisp. ... is what's important for understanding my analogy. ... The POSIX standard is analogous to the hyperspec. ...
    (comp.lang.lisp)
  • Re: Xen & VMI?
    ... Linux guest they will just stick with those ABIs - and worse, ... separately from Linux, then they should be tied together behind one ABI, ... but there is no danger of KVM ... staying in legacy land forever. ...
    (Linux-Kernel)