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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/virtualization
