Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Ingo Molnar]

* Pekka Enberg <address@hidden> wrote:

> On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
> >>It's not just about code, it's as much about culture and development 
> >>process.
> >
> >Indeed.  The BSDs have both kernel and the base system in a single
> >repository.  There are probably good reasons for (and against) it.
> >
> > In Linux we don't have that culture.  No tool (except perf) lives 
> > in the kernel repo.  I fail to see why kvm-tool is that much 
> > different from udev, util-linux, iproute, filesystem tools, that 
> > it should be included.
> 
> You seem to think perf is an exception - I think it's going to be 
> the future norm for userspace components that are very close to the 
> kernel. That's in fact what Ingo was arguing for when he suggested 
> QEMU to be merged to the kernel tree.

Yep, and the answer i got from the Qemu folks when i suggested that 
merge was a polite "buzz off", along the lines of: "We don't want to 
do that, but feel free to write your own tool, leave Qemu alone."

Now that people have done exactly that some Qemu folks not only have 
changed their objection from "write your own tool" to "erm, write 
your own tool but do it the way *we* prefer you to do it" - they also 
started contributing *against* the KVM tool with predictable, once 
every 3 months objections against its upstream merge...

That's not very nice and not very constructive.

The only valid technical objection against tools/kvm/ that i can see 
would be that it's not useful enough yet for the upstream kernel 
versus other tools such as Qemu. In all fairness i think we might 
still be at that early stage of the project but it's clearly 
progressing very rapidly and i'm already using it on a daily basis 
for my own kernel testing purposes. During the Kernel Summit that's 
how i tested contemporary kernels on contemporary user-space 
remotely, without having to risk a physical reboot.

Thanks,

        Ingo