You have to admit that much of Qemu's past 2-3 years of development wasIf you are interested in the first-hand experience of the people who arePlease take a look at the kvm integration code in qemu as a fraction of the
doing the perf work then here it is: by far the biggest reason for perf
success and perf usability is the integration of the user-space tooling
with the kernel-space bits, into a single repository and project.
whole code base.
motivated by Linux/KVM (i'd say more than 50% of the code).
As such it's one
and the same code base - you just continue to define Qemu to be different from
KVM.
I very much remember how Qemu looked like _before_ KVM: it was a struggling,
dying project. KVM clearly changed that.
Would you accept (or at least not NAK) a new tools/kvm/ tool that buildsThe very move you are opposing so vehemently for KVM.I don't want to fracture a working community.
tooling from grounds up, while leaving Qemu untouched? [assuming it's all
clean code, etc.]
Although i have doubts about how well that would work 'against' your opinion:
such a tool would need lots of KVM-side features and a positive attitude from
you to be really useful. There's a lot of missing functionality to cover.
Seems like perf is also split, with sysprof being developed outside theI'd prefer if sysprof merged into perf as 'perf view' - but its maintainer
kernel. Will you bring sysprof into the kernel? Will every feature be
duplicated in prof and sysprof?
does not want that - which is perfectly OK.
So we are building equivalent
functionality into perf instead.
Think about it like Firefox plugins: the main Firefox project picks up the
functionality of the most popular Firefox plugins all the time. Session Saver,
Tab Mix Plus, etc. were all in essence 'merged' (in functionality, not in
code) into the 'reference' Firefox project.