Chris Wright wrote: > I agree that changing the interface to the low-level platform is tricky > and less isolated. But how does the VMI protect you from those changes? > It simply doesn't, the changes are still necessary. And the inflexibility > means the tough corner cases swept under the VMI rug are more difficult > to debug, get right, etc... > I actually disagree here. Yes, it will change over time. VMI was designed to be extensible and flexible - you can omit implementation for any calls you don't require, and with consensus, you can add new flags, fields, and calls where you need them. But VMI as it stands today is simply not sufficient to support the hypervisors which are here now. There are gaps, particularly with SMP support, which require significant changes to either the hypervisors, the kernel, or the VMI itself. There are many reasons these gaps still exist, but most prominently, the big reason is that nobody wanted to use a single ABI to interface to the hypervisor a year ago when we first proposed the VMI interface as a virtualization solution for Linux. In the end, I see no reason the technical issues can't be solved, but the larger questions about the future evolution of the interface and also some largely non-technical points, valid or not, have stalled the growth which we originally desired. At this point, the question of whether to pursue a common ABI is no longer a technical issue, it's no longer a management or evolutionary issue at all. It's a pragmatic issue about getting code that works into Linux today. It's about working together using what we have as a base, which is paravirt-ops, to get working code to users. We can always evolve the code in tree if we find a workable cross-vendor ABI that solves everyone's problems. But that is neither here nor there, because it isn't here today. Zach _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/virtualization
