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.