* Linus Torvalds <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
