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 [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]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
