linux-kernel - Re: [GIT PULL] KVM updates for the 3.4 merge window

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]

Date:	Mon, 16 Apr 2012 14:47:39 +0200
From:	Alexander Graf <agraf@...e.de>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Avi Kivity <avi@...hat.com>, Paul Mackerras <paulus@...ba.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	KVM list <kvm@...r.kernel.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Paul Mackerras <paulus@....ibm.com>
Subject: Re: [GIT PULL] KVM updates for the 3.4 merge window

On 02.04.2012, at 11:46, Benjamin Herrenschmidt wrote:

> On Mon, 2012-04-02 at 12:06 +0300, Avi Kivity wrote:
>>> The current process is such that it takes absolutely forever for our
>>> patches to get in, which is a major PITA for something in such state of
>>> active development.
>> 
>> If the patches were posted two weeks earlier, they would have gone in.
> 
> I believe on our side they were, but Alex took a while to make up his
> tree ... oh well..

Yes, because to me the kvm-ppc-next tree basically is the same semantically as -next for Avi. It's where patches cook a while to make sure they actually work. Nobody tests KVM PPC patches against kvm's master tree. All testing (compile and execution) happens against kvm-ppc-next.

That's why I don't see the point in having it cook again in Avi's tree. At the end of the day the patches will surely become way too chewy ;).

The alternative would be that I don't have a -next tree, just collect patches and immediately send them to Avi. That way the main kvm tree would be broken more often, but at least we don't get these horrible synchronization latencies.

Alex

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