From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support Date: Thu, 14 Apr 2011 11:52:26 +0200 Message-ID: <4DA6C3DA.5000706@redhat.com> 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=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Markus Armbruster Return-path: Received: from mx1.redhat.com ([209.132.183.28]:11645 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932079Ab1DNJuO (ORCPT ); Thu, 14 Apr 2011 05:50:14 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Am 14.04.2011 11:26, schrieb Markus Armbruster: > 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? I would hesitate to turn it into an external library, because I really don't feel like maintaining API compatibility across versions. That's simply not doable with the block layer as of today. For the long term it's something that we may consider, but would certainly require some serious work. If some changes are needed to make it more reusable in the short term (while still copying the code over), I probably wouldn't be opposed to that. Kevin