[Libguestfs] [PREVIEW ONLY] Refactor data transfer code

[Richard W.M. Jones]

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