On 03/01/2010 11:45 AM, Anthony Liguori wrote:
On 03/01/2010 02:56 PM, Ingo Molnar wrote:
- 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.
gcc and the kernel are quite closely coupled, btw.
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.
Yes. Yes.
We've all looked at the hulking hairy behemoth of qemu and said, I think
I can clean this beast up and make him look like a proper gentlemen.
Then we tried to shave off the excess hair, only to find not only did it
grow back as fast as we trimmed it, but his complexion underneath was
mottled and inconsistent, so much so that the hair was actually helping.
In the end, we just settled for dressing him up in a suit and tie.
Zach
--
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