* Zachary Amsden <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
