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 <kw...@redhat.com> 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 <kw...@redhat.com> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
