* Zachary Amsden <zamsden@xxxxxxxxxx> wrote: > > I guess there is some misunderstanding here, the tools/ directory that > > lives in the kernel _sources_, has no kernel source, its all userspace > > stuff. > > Yeah, no morning coffee :=) > > So instead we are advocating forking qemu into the kernel. That makes even > less sense. It's not sustainable or eco-friendly to either community. 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. - It's released together with the kernel, which gives a periodic 3 months release frequency. Not too slow, not too fast. - 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. - 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. - 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. - 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. 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. 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
