Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support

[Markus Armbruster <armbru@redhat.com>]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 14.04.2011 11:26, schrieb Markus Armbruster:
>> Kevin Wolf <kwolf@redhat.com> 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@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 <kwolf@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.
>> 
>> 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.