Current implementation of virDomainBlockPull is actually a subset of
virDomainBlockRebase with NULL base.
I suggest to add new generalised API call virDomainBlockRebase2 which
will serve as a superset of both and support params list.
Having params list is more flexible and extendible for future possible
improvements of qemu block-stream or block-copy.
Could you please outline your motivations to do this besides the last
paragraph?
I'm asking because I personally think that virDomainBlockRebase trying
to "magically" do either block-stream or block-copy was a mistake.
The mistake was partially rectified by having virDomainBlockCopy as the
proper endpoint for block-copy/blockdev-mirror.
We do lack a fully-featured interface for 'block-stream' (to do
intermediate layer pull) but I don't think the fix for it is to have
once again a API that does both.
Peter, thank you for your review. Actually, you're totally right - that
was my initial motivation: to provide better interface for
'block-stream'. I agree we don't have to mix stream and copy within
single API call.
I'll prepare v2 patchset with 'block-stream'-only API and keep in mind
all your code related comments.
Best regards,
Nikolai
