* Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: > On 03/01/2010 02:56 PM, Ingo Molnar wrote: > >Here's our experience with tools/perf/. Hosting the project in the kernel > >proper helped its quality immensely: > > > > - It's much easier to synchronize new features on the kernel side and on the > > user-space side. The two go hand in hand - they are often implemented in > > the same patch. > > Kernel features and qemu features usually don't have a great amount of > intersect. All of the problems you've described are strictly in the qemu > space. IMO that's a bug, not a feature. There should be a lot more interaction between kvm-qemu and KVM: for example Qemu should have a feature to install paravirt drivers in the guest, this would be helped by living in the kernel repo. > > > - It's released together with the kernel, which gives a periodic 3 months > > release frequency. Not too slow, not too fast. > > qemu release range in length from 3-6 months depending on > distribution schedules. They are very regular. The Linux kernel is released every 3 months, +- one week. Our experience is that even 6 months would be (way) too painful for distros. > > - Lots of eyeballs and interest. In its mere 8 months of existence > > tools/perf/ has attracted more than 60 contributors already, and 35 KLOC of > > new code has been written. > > In our last release, we had around 100 contributors and about 100 KLOC of > code written. We've got a lot of eyeballs and a lot of interest. Congrats! > > - Code quality requirements are that of the kernel's. No muck allowed and > > it's not hard to explain what kind of code is preferred. > > Code quality is subjective. We have a different coding style. That's somewhat of a problem when for example a KVM kernel-space developer crosses into Qemu code and back. Two separate styles, etc. I certainly remember a 'culture clash' when going from the kernel into Qemu and back. Different principles, different culture. It's better to standardize. I.e. i think it would be useful to make it more of 'one' project, instead of this separation. > > - Tool breakage bisection is a breeze: there's never any mismatch between > > tools/perf and the kernel counterpart. With a separate package we'd > > have more complex test and bisection scenarios. > > KVM has a backwards compatible ABI so there's no such thing as mismatch > between user and kernel space. perf too is ABI compatible (between releases) - still bisection is a lot easier because the evolution of a particular feature can be bisected back to. Btw., KVM certainly ha ABI breakages around 2.6.16(?) when it was added, even of released versions. Also, within a development version you sure sometimes iterate a new ABI component, right? With a time-coherent repository both intentional and unintentional breakages and variations can be bisected back to as they happened. This is an unconditional advantage and i made use of it numerous times. > > - Code distribution is easy: it comes with the kernel. This spreads the code > > far and wide. It's easy for kernel developers to jump in and help out, the > > latest devel code is always there, a single 'cd tools/perf/; make -j install' > > command away. > > - Code reuse: we started sharing/librarizing code with the kernel: bitmap.h, > > hash.h, list.h, rbtree.h, bitops.h, prefetch.h. > > You could argue that any project should be in the kernel for these > reasons. I see no reason why something as like KVM should be part > of the kernel and udev shouldn't be. Yes, you are quite correct: udev has been argued to be a prime candidate for tools/. (and some other kernel utilities as well) >From a design POV all 'system/kernel utilities', which make little sense without the kernel and are license compatible can (and arguably should) move there. Obviously there's no pressure to do so - it's only an opportunity. > > etc. > > > > In the KVM context this was obviously only a suggestion though. If i were > > hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the project > > has very close ties to kernel-KVM and repo level unification would create > > various synergies - but you are hacking on it, not me ;-) > > > > If i were doing it i'd probably start with a cleaned up and stripped down > > version of Qemu, to make it eligible for mainline kernel inclusion. > > You should try it. I think you'll find that it's not as obvious thing to do > as you think it is. A few years ago I looked into cleaning up Qemu, when i hacked KVM and Qemu. I also wanted to have a 'qemu light', which is both smaller and cleaner, and still fits to KVM. It didnt look particularly hard back then - but it's certainly not zero amount of work. Cleanups pay - they make a piece of code both more hackable, more debuggable and more appealing to new developers. (i suspect you have no argument with that notion) Also note that it wasnt me who suggested that Qemu wouldnt fit the kernel standards as-is - it was raised by others in this discussion. 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
