From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] Merging KVM QEMU changes upstream Date: Fri, 25 Jan 2008 18:43:34 +0000 Message-ID: <200801251843.37551.paul@codesourcery.com> References: <479A222E.4@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org Return-path: In-Reply-To: <479A222E.4-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org > Is this a reasonable merge strategy? We won't introduce regressions but > I can't guarantee these new things will work cross-architecture. I think it depends to some extent whether things will need rewriting to be made cross-architecture. In particular if this requires interface changes. This means either breaking existing guests, or having to support both interfaces. e.g. the extboot stuff seems like something that should be usable by all targets, except that the current interface looks like it's inherently x86 specific. Paul ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/