Why QCOW1? (was: [PATCH v2] kvm tool: add QCOW verions 1 read/write support)

[Markus Armbruster <armbru@redhat.com>]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 13.04.2011 21:26, schrieb Prasad Joshi:
>> The patch only implements the basic read write support for QCOW version 1
>> images. Many of the QCOW features are not implmented, for example
>>  - image creation
>>  - snapshot
>>  - copy-on-write
>>  - encryption
>
> Yay, more forks, more code duplication!
>
> 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?
>
> If you shared code, you also wouldn't have to use an obsolete, but
> simple-to-implement format, but could use some of the better maintained
> formats of qemu, like qcow2.
>
> Also at least your qcow1.c is lacking the copyright header. Please add
> this, otherwise you're violating the license.

As discussed already, reimplementing rather than sharing can be excused,
because the existing code is not ready for sharing.

What hasn't been discussed much is the other half of Kevin's remark: why
QCOW1?  Does anyone still use that old hag in anger?  The format people
actually use is QCOW2, and it is properly maintained.

Even for little-used QOW formats, there are more interesting choices:
QED and FVD.