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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Wolf <kwolf@xxxxxxxxxx> 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.
--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux