Kevin Wolf <kwolf@xxxxxxxxxx> writes: > Am 14.04.2011 11:26, schrieb Markus Armbruster: >> Kevin Wolf <kwolf@xxxxxxxxxx> 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 <kwolf@xxxxxxxxxx> 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 <kwolf@xxxxxxxxxx> 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. Unless we make QEMU's block drivers usable outside QEMU (and that means at least a static library without API guarantees), we can hardly chide others for reimplementing them. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
