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

Ingo Molnar
2011-11-07T11:59:45Z

* Pekka Enberg <penberg@cs.helsinki.fi> 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