While I appreciate the efforts to add clean qemu/kvm integration in
upstream, it's driving me mad.
Every merge I'm faced with regressions (mostly due to changing code, not
to upstream breakage) and need to fix things. Work done during merges
is very likely to contain errors since there's no incremental change to
review and test.
We now have two very different kvm implementations:
The upstream implementation:
- mostly clean
- crippled
- no smp
- no kernel irqchip
- no kernel pit
- no device assignment
- reduced support for older host kernels
- no ia64 support
- no nmi support
- no tpr patching
- almost totally untested (small userbase)
The downstream implementation:
- a tangled mess
- featureful and performant
#include <features from above>
- heavily tested (kvm-autotest, large kvm userbase, inclusion in distros)
What we have here is the classic rewrite fallacy (rewriting from scratch
is easier than fixing, now six months into the voyage with no end in
sight) coupled with inflicting pain to the largest contributor to qemu
(I mean the kvm community, not me personally). Meanwhile, new kvm
kernel features need to be implemented twice in userspace.
I propose that we stop this. It is fragmenting the development effort,
causing regressions (again, mostly through merge issues, but also
through new code duplicating old code incorrectly), and not really
helping upstream qemu. It's also the first case I've heard of where a
project competes with itself (well not really but it's a nice soundbite).
As a first step I've merged a copy of libkvm into qemu linkage (i.e. not
as a library), so we can start to use the upstream code (say, use
kvm_ioctl() from libkvm.c). It's not going to be easy, but what we have
now isn't working.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html