Kevin Wolf <[email protected]> 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 <[email protected]> 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 <[email protected]> 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? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
