* Avi Kivity <avi@xxxxxxxxxx> wrote: > On 03/17/2010 10:10 AM, Ingo Molnar wrote: > > > >> It's about who owns the user interface. > >> > >> 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. > > > > Of course illogical modularization complicates things 'significantly'. > > Who should own the user interface then? If qemu was in tools/kvm/ then we wouldnt have such issues. A single patch (or 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. > > Fast forward to 2010. The kernel side of KVM is maximum goodness - by far > > 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. > > Any qemu usability problems are because developers (or their employers) are > 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. The same has been said of oprofile as well: 'it somewhat sucks because we are 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) Thanks, Ingo -- 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
