lkml.org 
[lkml]   [2007]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Xen & VMI?
    Rusty Russell wrote:
    > On Tue, 2007-03-06 at 21:37 +0100, Ingo Molnar wrote:
    >
    >> maybe i shouldnt call it 'VMI' but 'the paravirt ABI'. I dont mind if
    >> it's the Xen ABI or the VMWare ABI or a mesh of the two - everyone can
    >> map their own internals to that /one/ ABI.
    >>
    >
    > I think it's an excellent aim, but it's *HARD*. I rejected this
    > approach earlier because I'm just not smart enough. (Yet?)
    >

    With VMI, I think we came within 90% of getting a cross vendor
    paravirt-ABI that satisfied everyone's needs. Nobody is smart enough to
    figure out the last 10% - it needs cooperation, trial, error, and
    experience dealing with each other's hypervisors.

    > The Linux side is fairly stable. The hardware side is changing, and the
    > hypervisor side is changing. This means the ABI will churn fairly fast.
    > The hypervisors are very different, which means the ABI will be very
    > wide.
    >
    > We could start with VMI and try to support Xen, KVM and lguest. It
    > would at least give us a better idea of the scope of the problem. But
    > IMHO it's a *huge* job.
    >

    Surely, given time, the technical issues can be worked out. In the
    meantime, the hardware has evolved, and many of the points that are now
    important have changed - and new issues have come into play that we
    can't anticipate yet. At some point, we will hopefully converge, but we
    might not, and it is a huge job. UDI had similarly lofty goals. It was
    started in 1998. Where is it today?

    But this isn't the problem. The problem is that nobody wants a single
    ABI. Just like no hardware vendors want a fixed ABI for their
    hardware. They need to innovate independently, and time to market and
    features are more important than being binary compatible with a bunch of
    competing vendors. They want to differentiate, and break away from an
    ABI, and as history repeats, again and again, this happens eventually
    with every ABI.

    So once the ivory tower is built, and you let all the kids in to play,
    they are going to have a party and you are going to start noticing chips
    and eventually cracks, and eventually the tower will go into disrepair
    and fall because somebody else has built a new and better one further
    down the road. Why go through that exercise if nobody sees any tangible
    benefit from it today?

    Paravirt-ops avoids this because it is an API, and because it is
    flexible, and because it can change with the kernel, and because it
    doesn't lock you into a legacy way of doing things, it allows you to
    fork and adapt and push legacy and future compatibility issues into the
    vendor backend modules, like VMI, where they should belong.

    Zach
    -
    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-07 04:09    [W:4.191 / U:0.344 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site