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 10:52:51 +0200 Message-ID: <4DA6B5E3.3020508@redhat.com> References: <1302722762-30517-1-git-send-email-prasadjoshi124@gmail.com> <4DA6AA2F.2020306@redhat.com> <4DA6B0D8.3010706@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: Pekka Enberg Return-path: Received: from mx1.redhat.com ([209.132.183.28]:4030 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756818Ab1DNIup (ORCPT ); Thu, 14 Apr 2011 04:50:45 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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. Kevin