Messages in this thread | | | Date | Fri, 9 Mar 2007 20:24:20 +0100 | From | Ingo Molnar <> | Subject | Re: ABI coupling to hypervisors via CONFIG_PARAVIRT |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, 9 Mar 2007, Ingo Molnar wrote: > > > > yes - but we already support the raw hardware ABI, in the native > > kernel. > > Why do you continue to call paravirt an ABI? > > We got over that. It's not. It's an API. > > VMI is an ABI.
Unfortunately i still dont see where i'm wrong, and i'm really trying to understand your argument. Is your argument that as long as an ABI (VMI) is never directly used but only used via wrapper functions (paravirt_ops), it has no effects whatsoever on the flexibility of the rest of the software and ceases to have any negative ABI effects? In my opinion that is an absurd (and incorrect) point so i guess you must mean something else, but i really cannot think what that is.
I never said paravirt_ops is an ABI. I say that the ABI(s) _behind_ paravirt_ops [in the backend] /does/ limit Linux, even if wrapped, inevitably, and that i'm simply worried about having 4-5 independent ABIs behind each paravirt_ops variant each creating a web of design constraints on the rest of the kernel. To quote a past email of mine:
|| 'paravirt ops can take care of it' - but that is just blatantly || _FALSE_: the ABI 'behind' the paravirt_ops 'shines through' via || functional coupling
it doesnt matter in how big letters the wrapper functions have 'freedom' written on them, the _real_ constraint is the user's expectation to have the hypervisor work with Linux that worked with that particular VMI ABI in v2.6.21. So the user wants to have its hypervisor 1.12 work with Linux v2.6.22 - without having to update the hypervisor. And Linux v2.6.23. Etc. /That/ is the 'ABI effect' i'm worried about. It is a "compatibility web" that gets more and more entangled with every new paravirt_ops implementation added.
In practice, when a problem comes up during code rewrite, 90% of the time we can probably find a way around it via paravirt_ops and the backend, but i'm simply worried about the remaining 10%. And that 10% is not hypothetical at all, should i cite specific examples of problems that i think cannot be solved via Linux-only modifications?
I'm also worried about the sheer QA inertia of having an additional 4-5 hypervisor-ABI constraints on the correctness of the kernel, in addition to the 2 main CPU variants we have at the moment.
If we said "paravirt_ops must behave like real hardware" then we'd probably remove some of that risk (although enforcement is still an issue). But we _specifically_ say that no, it doesnt have to behave like real hardware. We allow shortcuts, we allow modifications of behavior - and that's good in quite many cases. But we allow really weird hacks like the .safe_halt() thing. Our only present requirement it appears is that "it works with today's hypervisor" - and that requirement automatically transforms itself into: "all future kernels will work with all past versions of the 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/
| |