* Avi Kivity<avi@xxxxxxxxxx> wrote:
On 03/17/2010 10:10 AM, Ingo Molnar wrote:If qemu was in tools/kvm/ then we wouldnt have such issues. A single patch (or
Who should own the user interface then?It's about who owns the user interface.Of course illogical modularization complicates things 'significantly'.
If qemu owns the user interface, than we can satisfy this in a very
simple way by adding a perf monitor command. If we have to support third
party tools, then it significantly complicates things.
series of patches) could modify tools/kvm/, arch/x86/kvm/, virt/ and
tools/perf/.
Numerous times did we have patches to kernel/perf_event.c that fixed some
detail, also accompanied by a tools/perf/ patch fixing another detail. Having
a single 'culture of contribution' is a powerful way to develop.
It turns out kernel developers can be pretty good user-space developers as
well and user-space developers can be pretty good kernel developers as well.
Some like to do both - as long as it's all within a single project.
The moment any change (be it as trivial as fixing a GUI detail or as complex
as a new feature) involves two or more packages, development speed slows down
to a crawl - while the complexity of the change might be very low!
Also, there's the harmful process that people start categorizing themselves
into 'I am a kernel developer' and 'I am a user space programmer' stereotypes,
which limits the scope of contributions artificially.
The same has been said of oprofile as well: 'it somewhat sucks because we areFast forward to 2010. The kernel side of KVM is maximum goodness - by farAny qemu usability problems are because developers (or their employers) are
the worst-quality remaining aspects of KVM are precisely in areas that you
mention: 'if we have to support third party tools, then it significantly
complicates things'. You kept Qemu as an external 'third party' entity to
KVM, and KVM is clearly hurting from that - just see the recent KVM
usability thread for examples about suckage.
not interested in fixing them, not because of the repository location. Most
kvm developer interest is in server-side deployment (even for desktop
guests), so there is limited effort in implementing a virtualbox-style GUI.
too server centric', 'nobody is interested in good usability and oprofile is
fine for the enterprises'. Ironically, the same has been said of Xen usability
as well, up to the point KVM came around.
What was the core of the problem was a bad design and a split kernel-side
user-side tool landscape.
In fact i think saying that 'our developers only care about the server' is
borderline dishonest, when at the same time you are making it doubly sure (by
inaction) that it stays so: by leaving an artificial package wall between
kernel-side KVM and user-side KVM and not integrating the two technologies.
You'll never know what heights you could achieve if you leave that wall there
...
Furthermore, what should be realized is that bad usability hurts "server
features" just as much. Most of the day-to-day testing is done on the desktop
by desktop oriented testers/developers. _Not_ by enterprise shops - they tend
to see the code years down the line to begin with ...
Yes, a particular feature might be server oriented, but a good portion of our
testing is on the desktop and everyone is hurting from bad usability and this
puts limits on contribution efficiency.
As the patch posted in _this very thread demonstrates it_, it is doubly more
difficult to contribute a joint KVM+Qemu feature, because it's two separate
code bases, two contribution guidelines, two release schedules. While to the
user it really is just one and the same thing. It should be so for the
developer as well.
Put in another way: KVM's current split design is making it easy to contribute
server features (because the kernel side is clean and cool), but also makes it
artificially hard to contribute desktop features: because the tooling side
(Qemu) is 'just another package', is separated by a package and maintenance
wall
and is made somewhat uncool by a (as some KVM developers have pointed out
in this thread) quirky codebase.
(the rest of your points are really a function of this fundamental
disagreement)