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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
Regards,
Anthony Liguori
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
