From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support Date: Thu, 14 Apr 2011 11:26:07 +0200 Message-ID: References: <1302722762-30517-1-git-send-email-prasadjoshi124@gmail.com> <4DA6AA2F.2020306@redhat.com> <4DA6B0D8.3010706@redhat.com> <4DA6B5E3.3020508@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pekka Enberg , Prasad Joshi , mingo@elte.hu, kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, levinsasha928@gmail.com, stefanha@linux.vnet.ibm.com To: Kevin Wolf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54563 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756818Ab1DNJ0h (ORCPT ); Thu, 14 Apr 2011 05:26:37 -0400 In-Reply-To: <4DA6B5E3.3020508@redhat.com> (Kevin Wolf's message of "Thu, 14 Apr 2011 10:52:51 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Kevin Wolf writes: > Am 14.04.2011 10:32, schrieb Pekka Enberg: >> Hi Kevin! >> >> Am 14.04.2011 10:21, schrieb Pekka Enberg: >>>> On Thu, Apr 14, 2011 at 11:02 AM, Kevin Wolf wrote: >>>>> Have you thought about a way to actually share code with qemu instead of >>>>> repeating Xen's mistake of copying code, modifying it until merges are >>>>> no longer possible and then let it bitrot? >>>> >>>> No we haven't and we're not planning to copy QEMU code as-is but >>>> re-implement support for formats we're interested in. >> >> On Thu, Apr 14, 2011 at 11:31 AM, Kevin Wolf wrote: >>> Okay. I might not consider it wise, but in the end it's your decision. >>> I'm just curious why you think this is the better way? >> >> Well, how would you go about sharing the code without copying in >> practical terms? We're aiming for standalone tool in tools/kvm of the >> Linux kernel so I don't see how we could do that. > > Well, copying in itself is not a big problem as long as the copies are > kept in sync. It's a bit painful, but manageable. Implementing every > image format twice (and implementing image formats in a reliable and > performing way isn't trivial) is much more painful. > > If you take the approach of "getting inspired" by qemu and then writing > your own code, the code will read pretty much the same, but be different > enough that a diff between both trees is useless and a patch against one > tree is meaningless for the other one. > > The block drivers are relatively isolated in qemu, so I think they > wouldn't pull in too many dependencies. Are you suggesting to turn QEMU's block drivers into a reasonably general-purpose library?