* 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/