Re: [libvirt] [PATCHv4 16/18] blockjob: add virDomainBlockCopy

>>> /** >>> + * virDomainBlockCopy: >>> + * @dom: pointer to domain object >>> + * @disk: path to the block device, or device shorthand >>> + * @dest: path to the copy destination >>> + * @format: format of the destination >>> + * @bandwidth: (optional) specify copy bandwidth limit in Mbps >>> + * @flags: bitwise-OR of virDomainBlockCopyFlags >> >> OK, so this new API may be used to avoid format guessing involved in >> virDomainBlockRebase. Shouldn't we introduce an enhanced version of >> virDomainBlockRebase with format parameter instead of introducing an API with >> a different name that does almost the same as virDomainBlockRebase? > > And what would you name it? I'm saying that virDomainBlockCopy _is_ an > enhanced virDomainBlockRebase, and the name BlockCopy was the name I > picked, as it looks nicer than virDomainBlockRebase2(). I don't know, I was probably expecting something like virDomainBlockRebaseExt :-P I'm just missing a clear link between virDomainBlockRebase and virDomainBlockCopy. I guess a note to virDomainBlockRebase documentation mentioning virDomainBlockCopy as an enhanced version would work too.

+++ b/src/libvirt.c @@ -18263,7 +18263,11 @@ error: * return an error if bandwidth is not 0. * * When @base is NULL and @flags is 0, this is identical to - * virDomainBlockPull(). + * virDomainBlockPull(). Conversely, when @flags includes + * VIR_DOMAIN_BLOCK_REBASE_COPY, this is shorthand for + * virDomainBlockCopy(dom, disk, base, + * flags & VIR_DOMAIN_BLOCK_COPY_RAW ? "raw" : NULL, bandwidth, + * flags &

/** + * virDomainBlockCopy:

+ * + * When @format is NULL, this is equivalent to calling + * virDomainBlockRebase() with the VIR_DOMAIN_BLOCK_REBASE_COPY flag

+ * to @flags. Additionally, if @format is "raw", this is equivalent to + * calling virDomainBlockRebase() with the VIR_DOMAIN_BLOCK_REBASE_COPY + * and VIR_DOMAIN_BLOCK_REBASE_COPY_RAW flags added to @flags.

> I guess I should wait for more feedback on the qemu front before > committing to the final form of this proposed libvirt API. Yeah, I think that's wise.