[lkml]   [2006]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: A proposal - binary
    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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-08-03 23:43    [W:0.030 / U:3.536 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site