* Andrew Morton <[email protected]> wrote:
> > Furthermore, why should we hamper Xen by going to _any_ sort of
> > "formalized" hypervisor API, when we dont even know what we want, as Xen
> > is pretty much work in progress? And whatever Xen support is exported
> > from the kernel, it should be a _GPL symbol export. We dont want to tie
> > down things like pagetable format or access methods. It's a very much
> > kernel-internal thing.
>
> Well that's the other side of the coin. I told the vmware guys to GPL
> their hypervisor to make this issue go away, but that hasn't happened
> yet ;)
>
> I think we need to deliberately deal with all this purely at the
> technical level and to carefully set aside thoughts such as the above.
> Others would disagree with that.
mine are mostly technical arguments. I just also wanted to vent away
this slowly gathering false notion of building 'interoperability', while
the only apparent goal seems to be to maximize benefits to the closed
hypervisors, while allowing them to not open up their code.
just grep the historic Linux changelogs for contributions from the most
prominent of these closed-source hypervisors. It's quite close to zero.
That's what Linux wins from this one-way relationship. Now the action
was forced by Xen, and it sounds so hypocritical to me to talk about
'interoperability'. Once the goal of having the APIs to pull even with
Xen has been achieved, that prominent closed-source hypervisor vendor
could just as easily go back into 'take from Linux'-only mode, as
they've done for so many years.
> At the technical level, I do think that the kernel->hypervisor
> interface is a brand new and *major* kernel interface. As such, it
> simply seems good design to put some thought and some formality into
> it. If that interface suits more than one paravirtualised hypervisor
> implementation then that's a sign that it has succeeded.
it just wont be done right first time around. It will be like with all
the other APIs we had: they went through dozens of major iterations, and
will go through iterations as the hardware changes and things get
cleaned up.
And yes, i do believe the Xen hypervisor should eventually live within
Linux itself. (i.e. Linux should be extended to offer hypervisor
services. This would enable to share drivers and technologies, etc.) No
specifications, no formal agreements necessary - just hack away and
things will be sorted out as they happen.
and no, it's not like with syscalls, for a number of reasons -
hypervisor/OS-kernel integration is a brand-new thing (at least in the
OSS space).
> The other design approach is to make this interface purely some
> xen-private thing which the Xen guys maintain and the rest of us don't
> worry about much. That's also a legitimate approach, but my current
> thinking is that it's technically not as good. Plus other hypervisor
> development teams may come along and have to graft their stuff onto
> the xen-interface-of-the-day, which isn't good.
having a robust API never hurts, no doubt about that - and Xen has
pretty good hypervisor APIs to begin with. But there is no connection
between formality and a technological sound API - you can have a crap
formal API just as much as you can have a good non-formal API. (e.g. the
current Linux device driver APIs are good non-formal APIs)
in fact, history has shown that formality often _hurts_ the
technological soundness of an API, mostly due to the inflebility and the
inherent lag inserted between design and implementation.
Formalizing an API if Xen asks for it is OK in my book, but formalizing
an API mostly for the sake of bin-only virtualization, under the
pretense of 'interoperability' sounds pretty backwards to me.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |