Re: [PATCH] abstract out bits of ldt.c

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/