From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932134AbbBZLCg (ORCPT <rfc822;w@1wt.eu>);
	Thu, 26 Feb 2015 06:02:36 -0500
Received: from static.88-198-71-155.clients.your-server.de ([88.198.71.155]:45839
	"EHLO socrates.bennee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932077AbbBZLCe (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 26 Feb 2015 06:02:34 -0500
References: <54DDD465.3050300@arm.com> <20150218155042.GF22017@arm.com> <54EAFCE9.5030000@arm.com>
From: Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Will Deacon <will.deacon@arm.com>, Cyrill Gorcunov <gorcunov@gmail.com>,
        "kvm\@vger.kernel.org" <kvm@vger.kernel.org>,
        Marc Zyngier <Marc.Zyngier@arm.com>, Asias He <asias.hejun@gmail.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Pekka Enberg <penberg@kernel.org>,
        Ronald Minnich <rminnich@google.com>,
        Sasha Levin <sasha.levin@oracle.com>,
        "kvmarm\@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
        "linux-arm-kernel\@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: stand-alone kvmtool
In-reply-to: <54EAFCE9.5030000@arm.com>
Date: Thu, 26 Feb 2015 11:02:31 +0000
Message-ID: <87mw41aqbc.fsf@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: alex.bennee@linaro.org
X-SA-Exim-Scanned: No (on socrates.bennee.com); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


Andre Przywara <andre.przywara@arm.com> writes:

> Hi Will,
>
> On 18/02/15 15:50, Will Deacon wrote:
>> Hi Andre,
>> 
>> Thanks for doing this. Since it looks unlikely that kvmtool will ever be
>> merged back into the kernel tree, it makes sense to cut the dependency
>> in my opinion.
>> 
<snip>
>
> P.S. Although both approaches still provide the kvmtool patch history,
> they do not compile before the dependency cut patches. If that is an
> issue, one could think about injecting those new patches back into the
> repository time line. Admittedly that sounds scary, but would solve the
> problem.

If you can have it all it would be nice to preserve buildability all
through your history for bisecting (and the moon on a stick please ;-)

Is the dependency on the kernel sources something that has been stable
over the projects history or something that's been declining/increasing
over time?

-- 
Alex Bennée