From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXDzV-0001yj-2U for qemu-devel@nongnu.org; Thu, 16 Jun 2011 10:56:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXDzL-0000z9-9n for qemu-devel@nongnu.org; Thu, 16 Jun 2011 10:56:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXDzK-0000yz-HA for qemu-devel@nongnu.org; Thu, 16 Jun 2011 10:56:06 -0400 Date: Thu, 16 Jun 2011 11:55:43 -0300 From: Marcelo Tosatti Message-ID: <20110616145543.GC12173@amt.cnet> References: <1308075511-4745-1-git-send-email-stefanha@linux.vnet.ibm.com> <4DF9F899.5050301@redhat.com> <20110616143848.GA12173@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110616143848.GA12173@amt.cnet> Subject: Re: [Qemu-devel] Image streaming and live block copy (was: [PATCH 00/13] QED image streaming) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Anthony Liguori , Stefan Hajnoczi , jes sorensen , Dor Laor , qemu-devel@nongnu.org, Avi Kivity , Adam Litke On Thu, Jun 16, 2011 at 11:38:48AM -0300, Marcelo Tosatti wrote: > > People seem to agree on this, and the reason that I've heard why we > > should merge the existing code instead is downstream time pressure. That > > may be a valid reason for downstreams to add such code, but is taking > > such code really the best option for upstream (and therefore long-term > > for downstreams)? > > > > If we take these patches as they are, I doubt that we'll ever get a > > rewrite to implement the code as it should have been done in the first > > place. > > That (a newer, unified mechanism) is just a matter of allocating > resources to the implementation. > > At least in block copy's case the interface can be reused, so it can be > seen as an incremental approach (read: advocating in favour of merging > live block copy patchset). > > > So I'm tempted to reject the current versions of both the image > > streaming and live block copy series and leave it to downstreams to use > > these as temporary solutions if the time pressure is too high. I know > > that maintaining things downstream is painful, but that's the whole > > point: I want to see the real implementation one day, and I'm afraid > > this might be the only way to get it. Again: there is no need to reject current live block copy implementation, as image streaming implemented for generic image formats is a strong motivator behind the unified implementation.