Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
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. Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
* Kevin Wolf kw...@redhat.com wrote: Also at least your qcow1.c is lacking the copyright header. Please add this, otherwise you're violating the license. AFAICT it's not a copy, it's a reimplementation - and he credited you in the CREDITS file, for providing a reference implementation. But we can credit you to the header as well - Pekka? Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
Am 14.04.2011 10:07, schrieb Ingo Molnar: * Kevin Wolf kw...@redhat.com wrote: Also at least your qcow1.c is lacking the copyright header. Please add this, otherwise you're violating the license. AFAICT it's not a copy, it's a reimplementation - and he credited you in the CREDITS file, for providing a reference implementation. But we can credit you to the header as well - Pekka? It's actually not my code, but Fabrice's. I compared get_cluster_offset() and it looks similar enough to me to qualify as a modified copy. Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
* Kevin Wolf kw...@redhat.com wrote: Also at least your qcow1.c is lacking the copyright header. Please add this, otherwise you're violating the license. Am 14.04.2011 10:07, schrieb Ingo Molnar: AFAICT it's not a copy, it's a reimplementation - and he credited you in the CREDITS file, for providing a reference implementation. But we can credit you to the header as well - Pekka? On Thu, Apr 14, 2011 at 11:12 AM, Kevin Wolf kw...@redhat.com wrote: It's actually not my code, but Fabrice's. I compared get_cluster_offset() and it looks similar enough to me to qualify as a modified copy. It's actually me who asked to drop the license banners from the file and move it to CREDITS. Parasd, mind sending a patch that adds it back to the files? Pekka -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
On Thu, Apr 14, 2011 at 11:02 AM, Kevin Wolf kw...@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:02 AM, Kevin Wolf kw...@redhat.com wrote: 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. We're adding QCOW2 too and hopefully other non-QEMU formats as well. On Thu, Apr 14, 2011 at 11:02 AM, Kevin Wolf kw...@redhat.com wrote: Also at least your qcow1.c is lacking the copyright header. Please add this, otherwise you're violating the license. Thanks, will fix! Pekka -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
Am 14.04.2011 10:15, schrieb Pekka Enberg: * Kevin Wolf kw...@redhat.com wrote: Also at least your qcow1.c is lacking the copyright header. Please add this, otherwise you're violating the license. Am 14.04.2011 10:07, schrieb Ingo Molnar: AFAICT it's not a copy, it's a reimplementation - and he credited you in the CREDITS file, for providing a reference implementation. But we can credit you to the header as well - Pekka? On Thu, Apr 14, 2011 at 11:12 AM, Kevin Wolf kw...@redhat.com wrote: It's actually not my code, but Fabrice's. I compared get_cluster_offset() and it looks similar enough to me to qualify as a modified copy. It's actually me who asked to drop the license banners from the file and move it to CREDITS. Parasd, mind sending a patch that adds it back to the files? Heh, I just saw your mail from yesterday. Missed it because I wasn't CCed on v1. The license is pretty clear about it: * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. You could discuss if it would be enough to copy the license text into CREDITS, but leaving it in the file is the usual and expected way. Anyway, license issues are not my favourite topic, I would rather discuss ways of sharing code instead of creating more unmergeable forks. Don't you feel that it will hurt both sides if you continue this way? Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
* Kevin Wolf kw...@redhat.com wrote: Am 14.04.2011 10:07, schrieb Ingo Molnar: * Kevin Wolf kw...@redhat.com wrote: Also at least your qcow1.c is lacking the copyright header. Please add this, otherwise you're violating the license. AFAICT it's not a copy, it's a reimplementation - and he credited you in the CREDITS file, for providing a reference implementation. But we can credit you to the header as well - Pekka? It's actually not my code, but Fabrice's. I compared get_cluster_offset() and it looks similar enough to me to qualify as a modified copy. Well, i asked Prasad whether he copied any code and he said no (so it's not a copy AFAICT) - but i nevertheless asked him to add proper attribution in any case because he used it as a reference. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
* Kevin Wolf kw...@redhat.com wrote: Am 14.04.2011 10:15, schrieb Pekka Enberg: * Kevin Wolf kw...@redhat.com wrote: Also at least your qcow1.c is lacking the copyright header. Please add this, otherwise you're violating the license. Am 14.04.2011 10:07, schrieb Ingo Molnar: AFAICT it's not a copy, it's a reimplementation - and he credited you in the CREDITS file, for providing a reference implementation. But we can credit you to the header as well - Pekka? On Thu, Apr 14, 2011 at 11:12 AM, Kevin Wolf kw...@redhat.com wrote: It's actually not my code, but Fabrice's. I compared get_cluster_offset() and it looks similar enough to me to qualify as a modified copy. It's actually me who asked to drop the license banners from the file and move it to CREDITS. Parasd, mind sending a patch that adds it back to the files? Heh, I just saw your mail from yesterday. Missed it because I wasn't CCed on v1. The license is pretty clear about it: * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. Note that Prasad's v0 patch did not include this copyright notice - because he wrote the file from scratch. I asked him to attribute the Qemu reference implementation in any case - which he understood as copying the copyright license verbatim. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
Am 14.04.2011 10:21, schrieb Pekka Enberg: On Thu, Apr 14, 2011 at 11:02 AM, Kevin Wolf kw...@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. 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? Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
Hi Kevin! Am 14.04.2011 10:21, schrieb Pekka Enberg: On Thu, Apr 14, 2011 at 11:02 AM, Kevin Wolf kw...@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 kw...@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. Pekka -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
On Thu, Apr 14, 2011 at 11:32:21AM +0300, Pekka Enberg wrote: Hi Kevin! Am 14.04.2011 10:21, schrieb Pekka Enberg: On Thu, Apr 14, 2011 at 11:02 AM, Kevin Wolf kw...@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 kw...@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. You mean you would not be ok with linking with anything other then glibc? Pekka -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
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 kw...@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 kw...@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. Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
On Thu, Apr 14, 2011 at 9:27 AM, Ingo Molnar mi...@elte.hu wrote: * Kevin Wolf kw...@redhat.com wrote: Am 14.04.2011 10:15, schrieb Pekka Enberg: * Kevin Wolf kw...@redhat.com wrote: Also at least your qcow1.c is lacking the copyright header. Please add this, otherwise you're violating the license. Am 14.04.2011 10:07, schrieb Ingo Molnar: AFAICT it's not a copy, it's a reimplementation - and he credited you in the CREDITS file, for providing a reference implementation. But we can credit you to the header as well - Pekka? On Thu, Apr 14, 2011 at 11:12 AM, Kevin Wolf kw...@redhat.com wrote: It's actually not my code, but Fabrice's. I compared get_cluster_offset() and it looks similar enough to me to qualify as a modified copy. It's actually me who asked to drop the license banners from the file and move it to CREDITS. Parasd, mind sending a patch that adds it back to the files? Heh, I just saw your mail from yesterday. Missed it because I wasn't CCed on v1. The license is pretty clear about it: * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. Note that Prasad's v0 patch did not include this copyright notice - because he wrote the file from scratch. I asked him to attribute the Qemu reference implementation in any case - which he understood as copying the copyright license verbatim. Oh God. I was walking to university on seventh cloud, hoping to work on caching the l2 table. Now I find myslef under the controversy. Frankly speaking I am very new to understand the intricacies of licensing, I won't mind copying the copyright notice in the code if it is necessary. I am also okay with attributing the code to developers of QEMU. Speaking about the code of finding the cluster offset is so basic, that I thought it should be implemented the way it is done in the QEMU. But none of the code is copied from the QEMU sources. The complete code is written from scratch with QEMU sources as a reference. I avoid sending the first few versions of the patches on KVM mailing list, the code contains lots of structural mistakes and needs revisions. I don;t want to flood mailing list with those revisions. The kvm tool community is kind enough to guide me in improving the code, when infact any one of them can write the code in lesser time than mine. Forgive me for my lack of knowledge, I hope this problem would be solved soon. Thanks and Regards, Prasad Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
Kevin Wolf kw...@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 kw...@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 kw...@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? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
* Prasad Joshi prasadjoshi...@gmail.com wrote: Speaking about the code of finding the cluster offset is so basic, that I thought it should be implemented the way it is done in the QEMU. But none of the code is copied from the QEMU sources. The complete code is written from scratch with QEMU sources as a reference. [...] I think we should put that info into a prominent place in the source file together with a very prominent acknowledgement to the Qemu implementation as well. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
Am 14.04.2011 11:26, schrieb Markus Armbruster: Kevin Wolf kw...@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 kw...@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 kw...@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. Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
On Thu, Apr 14, 2011 at 11:26:07AM +0200, Markus Armbruster wrote: Kevin Wolf kw...@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 kw...@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 kw...@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? This is useful not just for native kvm, but also for people writing tools or automating their KVM setups. Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
On 4/14/11 12:23 PM, Prasad Joshi wrote: Oh God. I was walking to university on seventh cloud, hoping to work on caching the l2 table. Now I find myslef under the controversy. Again, it's my fault, not yours. I asked to remove the license banner on top of qcow1.c because it doesn't contain any copied code. I will fix it up. Thanks! Pekka -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
Kevin Wolf kw...@redhat.com writes: Am 14.04.2011 11:26, schrieb Markus Armbruster: Kevin Wolf kw...@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 kw...@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 kw...@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. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
On 04/14/2011 03:52 AM, Kevin Wolf wrote: 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. The block layer has some interesting bits though that I can understand wanting to avoid (like aio emulation). In the very least, we've learned the hard way that getting an image format right is very hard. A good test suite is worth it's weight in gold for something like this. When taking the approach of starting fresh, doing test driven development is definitely worth considering. Regards, Anthony Liguori Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm tool: add QCOW verions 1 read/write support
On Wed, 13 Apr 2011, Prasad Joshi wrote: The patch only implements the basic read write support for QCOW version 1 images. Many of the QCOW features are not implmented, for example Applied, thanks! Pekka -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
