Re: A proposal - binary

From: Zachary Amsden
Date: Thu Aug 03 2006 - 17:39:10 EST


Greg KH wrote:
On Thu, Aug 03, 2006 at 12:26:16PM -0700, Zachary Amsden wrote:
Greg KH wrote:
Sorry, but we aren't lawyers here, we are programmers. Do you have a
patch that shows what you are trying to describe here? Care to post it?
<Posts kernel/module.c unmodified>

If you want to stick with the current kernel module interface, I don't
see why you even need to bring this up, there are no arguments about
that API being in constant flux :)

Hence my point follows. Using source compiled with the kernel as a module does nothing to provide a stable interface to the backend hardware / hypervisor implementation.

How does this differ with the way that the Xen developers are proposing?
Why haven't you worked with them to find a solution that everyone likes?
We want our backend to provide a greater degree of stability than a pure source level API as the Xen folks have proposed. We have tried to convince them that an ABI is in their best interest, but they are reluctant to commit to one or codesign one at this time.

Don't you feel it's a bit early to "commit" to anything yet when we
don't have a working implementation? Things change over time, and it's
one of the main reasons Linux is so successful.

We have a working implementation of an ABI that interfaces to both ESX and Xen. I have no argument that things change over time, and that helps Linux to be successful and adaptive. But the fact that things change so much over time is the problem. Distributing a hypervisor that runs only one particular version of some hacked up kernel is almost useless from a commercial standpoint. Most end users get their kernels from some distro, and these kernels have a long lifetime, while the release cycle for an entire OS distribution is getting much longer. During that time, the hypervisor and the kernel will diverge. If is not a question of if - it is a question of how much. A well designed ABI slows that divergence to a pace that allows some hope of compatibility. An ad-hoc source layer compatibility does not.


And what about Rusty's proposal that is supposed to be the "middle
ground" between the two competing camps? How does this differ from
that? Why don't you like Rusty's proposal?
Who said that? Please smack them on the head with a broom. We are all actively working on implementing Rusty's paravirt-ops proposal. It makes the API vs ABI discussion moot, as it allow for both.

So everyone is still skirting the issue, oh great :)

There are many nice things about Rusty's proposal that allow for a simpler and cleaner interface to Linux - for example, getting rid of the need to have a special hypervisor sub-architecture, and allowing non-performance critical operations to be indirected for flexibility of implementation.

The Xen ABI as it stands today is not cleanly done - it assumes too many details about how the hypervisor will operate, and is purely a hypervisor specific ABI. We and other vendors would have to bend over backwards and jump through flaming hoops while holding our breath in a cloud of sulfurous gas to implement that interface. And there is no guarantee that the interface will remain stable and compatible. So it is really a non-starter.

VMI as it stands today is hypervisor independent, and provides a much more stable and compatible interface. Although I believe it is possible that it could work for other vendors than just VMware and Xen, those other vendors could have their own, proprietary, single purpose ABI that is either deliberately hypervisor specific or accidentally so from a lack of forethought. <Zach removes soapbox>.

As you mention, Linux is adaptive and will change going forward. Rusty's proposal allows a way to accommodate that change until such a time as a true vendor independent hypervisor agnostic ABI evolves. Hopefully in time it will - but that is not the case today, despite our sincere efforts to make it happen. In fairness, we could have been more public and forthcoming about our interface, but we also have not received significant cooperation or collaboration on our efforts until the work on paravirt-ops began. With the code coming into public scrutiny and the goal of working together, perhaps our model can serve as a blueprint, or at least a rough draft of what a long term stable ABI will look like. But that is neither here nor there until the code is working and ready to go. Paravirt-ops provides a nice house for this - it lets us all speak the same language in Linux, even if we have to phone our hypervisor in Sanskrit and Xen speaks in Latin. Creating a common lingua franca is still an excellent goal, but we can't predict the future. Hopefully, nobody starts using smoke signals. In the end, paravirt-ops allows us all to play on the same field, and either a unified hypervisor independent solution will win, or the hypervisor interfaces will fragment, and Linux will still have an interface that allows it to run on multiple hypervisors. Either way, Linux gets more functionality and better performance in more environments, which is the real win.

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