linux-kernel - Re: [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: <4EB79000.5040308@redhat.com>
Date:	Mon, 07 Nov 2011 09:00:00 +0100
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Pekka Enberg <penberg@...nel.org>
CC:	Alexander Graf <agraf@...e.de>,
	"kvm@...r.kernel.org list" <kvm@...r.kernel.org>,
	qemu-devel Developers <qemu-devel@...gnu.org>,
	"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
	Blue Swirl <blauwirbel@...il.com>, Avi Kivity <avi@...hat.com>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels

On 11/06/2011 09:17 PM, Pekka Enberg wrote:
> >  No.  I want to try new tool/old kernel and old tool/new kernel (kernel can
> >  be either guest or host, depending on the nature of the bug), and then
> >  bisect just one.  (*) And that's the exceptional case, and only KVM tool
> >  developers really should have the need to do that.
>
> Exactly - having the source code in Linux kernel tree covers the
> "exceptional case" where we're unsure which part of the equation broke
> things (which are btw the nasties issues we've had so far).

No, having the source code in Linux kernel tree is perfectly useless for 
the exceptional case, and forces you to go through extra hoops to build 
only one component.  Small hoops such as adding "-- tools/kvm" to "git 
bisect start" perhaps, but still hoops that aren't traded for a 
practical advantage.  You keep saying "oh things have been so much 
better" because "it's so close to the kernel" and "it worked so great 
for perf", but you haven't brought any practical example that we can 
stare at in admiration.

(BTW, I'm also convinced like Ted that not having a defined perf ABI 
might have made sense in the beginning, but it has now devolved into bad 
software engineering practice).

> I have no idea why you're trying to convince me that it doesn't matter.

I'm not trying to convince you that it doesn't matter, I'm trying to 
convince you that it doesn't *make sense*.

> It's a hypervisor that implements virtio drivers, serial
> emulation, and mini-BIOS.

... all of which have a spec against which you should be working.  Save 
perhaps for the mini-BIOS, if you develop against the kernel source 
rather than the spec you're doing it *wrong*.  Very wrong.  But you've 
been told this many times already.

Paolo
--
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/