Re: [Libguestfs] [PREVIEW ONLY] Refactor data transfer code

This patch is not using hread/hwrite? Anyway I'd be interested in whether you can do all you wanted from hread/hwrite/hseek/etc using the proposed upload-offset API that I posted here: http://www.redhat.com/archives/libguestfs/2010-September/msg00026.html http://www.redhat.com/archives/libguestfs/2010-September/msg00027.html I tried implementing the 'hexedit' command using both APIs and using upload-offset the code was considerably simpler. Of course, while that's interesting, it is not necessarily comparable to what virt-v2v needs to do. One possible advantage for upload-offset is that you can stream data in without knowing or specifying in advance how much data you will stream in. Also the amount you can stream in has no protocol limits. So I imagine that you could stream data, while looking for zero-blocks, and when you reach a block of zeroes you would finish the current upload-offset call and start a new one after the block of zeroes finishes. Since this is all done at a byte level, there is no need for reads from the source to be in blocks, or to be aligned, or to have any maximum size. On a related topic: In the above email I claimed that because these use FileIn/FileOut, they should be more efficient. In fact once I measured it, I found there was not a lot of difference. But I'm still looking at why that is, because I'm fairly sure that FileIn/FileOut _ought_ to be more efficient than making lots of discrete non-pipelined API calls. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw