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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EB6BEFA.6000303@codemonkey.ws>
Date:	Sun, 06 Nov 2011 11:08:10 -0600
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Avi Kivity <avi@...hat.com>
CC:	Pekka Enberg <penberg@...nel.org>,
	"kvm@...r.kernel.org list" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
	qemu-devel Developers <qemu-devel@...gnu.org>,
	Alexander Graf <agraf@...e.de>,
	Blue Swirl <blauwirbel@...il.com>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test
 kernels

On 11/06/2011 10:50 AM, Avi Kivity wrote:
> On 11/06/2011 06:35 PM, Pekka Enberg wrote:
>>>> The difference here is that although I feel Alex's script is a
>>>> pointless project, I'm in no way opposed to merging it in the tree if
>>>> people use it and it solves their problem. Some people seem to be
>>>> violently opposed to merging the KVM tool and I'm having difficult
>>>> time understanding why that is.
>>>
>>> One of the reasons is that if it is merge, anyone with a #include
>>> <linux/foo.h>  will line up for the next merge window, wanting in.  The
>>> other is that anything in the Linux source tree might gain an unfair
>>> advantage over out-of-tree projects (at least that's how I read Jan's
>>> comment).
>>
>> Well, having gone through the process of getting something included so
>> far, I'm not at all worried that there's going to be a huge queue of
>> "#include<linux/foo.h>" projects if we get in...
>>
>> What kind of unfair advantage are you referring to? I've specifically
>> said that the only way for KVM tool to become a reference
>> implementation would be that the KVM maintainers take the tool through
>> their tree. As that's not going to happen, I don't see what the
>> problem would be.
>
> I'm not personally worried about it either (though in fact a *minimal*
> reference implementation might not be a bad idea).  There's the risk of
> getting informed in-depth press reviews ("Linux KVM Takes A Step Back
>  From Running Windows Guests"), or of unfairly drawing developers away
> from competing projects.

I don't think that's really a concern.  Competition is a good thing.  QEMU is a 
large code base that a lot of people rely upon.  It's hard to take big risks in 
a project like QEMU because the consequences are too high.

OTOH, a project like KVM tool can take a lot of risks.  They've attempted a very 
different command line syntax and they've put a lot of work into making 
virtio-9p a main part of the interface.

If it turns out that these things end up working out well for them, then it 
becomes something we can copy in QEMU.  If not, then we didn't go through the 
train wreck of totally changing CLI syntax only to find it was the wrong syntax.

I'm quite happy with KVM tool and hope they continue working on it.  My only 
real wish is that they wouldn't copy QEMU so much and would try bolder things 
that are fundamentally different from QEMU.

Regards,

Anthony Liguori

>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/