Re: [Xen-devel] [Patch 2/3] New blktap implementation

[Dutch Meyer <dmeyer@xxxxxxxxx>]

Basically the qcow tools as they exist in the xen repo are broken. 
img2raw doesn't zero its file descriptor, so polling on it can fail 
dramatically.  Unless I'm horribly mistaken the driver routines that open 
a qcow image, in trying to modify the endian of the L1 table, completely 
clobber the file header.
Likely this patch (or one like it) needs to be applied to the old blktap 
as well, insofar as it exists with this new blktap patch.
--Dutch

On Fri, 31 Oct 2008, Kevin Wolf wrote:

> Dutch Meyer schrieb:
> > Patch 2 of 3.
> >
> > Signed-off-by: Jake Wires <jake.wires@xxxxxxxxxx>, Dutch Meyer
> > <dmeyer@xxxxxxxxx>
> >
> > This is a new and rewritten version of blktap that we have developed at
> > Citrix.  The current version of blktap is left functionally unmodified.
> > The change set consists of three patches.
> You only have attached a fixqcow patch, no blktap rewrite.
>
> Could you explain what the qcow patch is supposed to fix? I think we
> need good reasons to change this code because every change increases the
> differences between the tapdisk and qemu implementation of the format.
> It was agreed that eventually we want to get rid of the tapdisk
> implementation of the formats qemu can provide, but in the meantime we
> should at least be careful not to increase differences.
>
> If these are real fixes, maybe they should also go into upstream qemu?
>
> Kevin
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel