lkml.org 
[lkml]   [2007]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ABI coupling to hypervisors via CONFIG_PARAVIRT

    * Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > Similarly, maybe the VMI ABI doesn't allow for something that the
    > kernel wants to do efficiently. Big deal. What relevance does that
    > have to do with anything, except the fact that if true, the VMWare
    > people are screwed? It's *their* problem.

    i wont hold you up for long, but i think this is the key difference, and
    if i understand your point correctly i think you are really wrong here.

    This is 'enterprise Linux compatibility and ABI 101', really - i dare to
    bet blindly that you wont see anyone here from distros arguing against
    this simple point.

    Once this thing is released upstream, it creates a new compatibility
    rule:

    _new kernel must not break on an older hypervisor_

    due to a new paravirt_ops design. Ever. It's really that simple. (I
    think i never said this explicitly because this requirement of backwards
    compatibility was so obvious to me.)

    And it doesnt matter whether we think that it was VMWare who messed up.
    Users/customers _will_ blame us: "v2.6.25 regresses, it wont run under
    ESX v1.12 anymore". Distro will yield and will undo whatever change
    breaks backwards compatibility with older hypervisors. (most likely it
    will be undone upstream already) Backwards compatibility acts as a very
    heavy barrier against certain types of paravirt_ops design changes.

    Once v2.6.21 is released, and a bigger distro releases a kernel with
    CONFIG_PARAVIRT+CONFIG_VMI enabled: backwards compatibility in future
    versions becomes mainly /that/ distro's problem (and upstream's
    problem), _NOT_ WMware's problem.

    That's why i mentioned CONFIG_COMPAT_VDSO as an example. One major
    distro (SuSE 9.0) came out with that particular glibc version that had a
    bug that depended on a particular and totally unintentional ABI detail
    in the vDSO. As a result we had to do several iterations of
    CONFIG_COMPAT_VDSO to keep backwards compatibility. And glibc is perhaps
    _the_ most kernel-friendly external software project in existence.
    Still, the ABI dependency was there, and we cannot break users who run
    old userspace. The same rule holds here: we cannot break users who run
    an old hypervisor.

    Ingo
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-03-09 21:17    [W:5.879 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site