From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: KVM call minutes for Feb 1 Date: Thu, 3 Feb 2011 08:13:17 -0200 Message-ID: <20110203101317.GA2826@amt.cnet> References: <20110201155414.GF28968@x200.localdomain> <4D48367D.2060802@siemens.com> <20110201175336.GA22653@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kiszka , Chris Wright , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Christoph Hellwig Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50660 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756086Ab1BCKQJ (ORCPT ); Thu, 3 Feb 2011 05:16:09 -0500 Content-Disposition: inline In-Reply-To: <20110201175336.GA22653@infradead.org> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Feb 01, 2011 at 12:53:36PM -0500, Christoph Hellwig wrote: > On Tue, Feb 01, 2011 at 05:36:13PM +0100, Jan Kiszka wrote: > > kvm_cpu_exec/kvm_run, and start wondering "What needs to be done to > > upstream so that qemu-kvm could use that implementation?". If they > > differ, the reasons need to be understood and patched away, either by > > fixing/enhancing upstream or simplifying qemu-kvm. Once the upstream > > changes are merged back, a qemu-kvm patch is posted to switch to that > > version. > > while I'm not an expert in that area I really like you're approach. I'd > really prefer to let you finish up all the major work that way before > starting massive revamping like the glib main loop. Resolving the > qemu/qemu-kvm schisma surely is more important for the overall project > than rewriting existing functionality to look a little nicer. Agree. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53729 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkwES-0000Z7-S4 for qemu-devel@nongnu.org; Thu, 03 Feb 2011 05:16:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkwER-0002cn-Bh for qemu-devel@nongnu.org; Thu, 03 Feb 2011 05:16:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkwER-0002cY-4m for qemu-devel@nongnu.org; Thu, 03 Feb 2011 05:16:07 -0500 Date: Thu, 3 Feb 2011 08:13:17 -0200 From: Marcelo Tosatti Message-ID: <20110203101317.GA2826@amt.cnet> References: <20110201155414.GF28968@x200.localdomain> <4D48367D.2060802@siemens.com> <20110201175336.GA22653@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110201175336.GA22653@infradead.org> Subject: [Qemu-devel] Re: KVM call minutes for Feb 1 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Chris Wright , Jan Kiszka , qemu-devel@nongnu.org, kvm@vger.kernel.org On Tue, Feb 01, 2011 at 12:53:36PM -0500, Christoph Hellwig wrote: > On Tue, Feb 01, 2011 at 05:36:13PM +0100, Jan Kiszka wrote: > > kvm_cpu_exec/kvm_run, and start wondering "What needs to be done to > > upstream so that qemu-kvm could use that implementation?". If they > > differ, the reasons need to be understood and patched away, either by > > fixing/enhancing upstream or simplifying qemu-kvm. Once the upstream > > changes are merged back, a qemu-kvm patch is posted to switch to that > > version. > > while I'm not an expert in that area I really like you're approach. I'd > really prefer to let you finish up all the major work that way before > starting massive revamping like the glib main loop. Resolving the > qemu/qemu-kvm schisma surely is more important for the overall project > than rewriting existing functionality to look a little nicer. Agree.