On Fri, Apr 13, 2012 at 15:42:20 -0600, Eric Blake wrote:
> On 04/13/2012 03:25 PM, Jiri Denemark wrote:
> > On Mon, Apr 09, 2012 at 21:52:25 -0600, Eric Blake wrote:
> >> This new API provides additional flexibility over what can be
> >> crammed on top of virDomainBlockRebase (namely, the ability to
> >> specify an arbitrary destination format, for things like copying
> >> qcow2 into qed without having to pre-create the destination), at
> >> the expense that it cannot be backported without bumping the .so
> >> version.
> >>
>
> >> +typedef enum {
> >> + VIR_DOMAIN_BLOCK_COPY_SHALLOW = 1 << 0, /* Limit copy to top of source
> >> + backing chain */
> >> + VIR_DOMAIN_BLOCK_COPY_REUSE_EXT = 1 << 1, /* Reuse existing external
> >> + file for a copy */
> >> +} virDomainBlockCopyFlags;
> >
> > Hmm, we have several flags enums that end up being passed to a single internal
> > API and one has to be extra careful when adding new flags. Should we make a
> > note about this to the affected enums?
>
> Yes, a note would be helpful (it's only the two least-significant bits
> that we are playing fast and loose with at the moment, but if we ever
> expand to a third common bit, I see where it could get confusing).
>
> >>
> >> /**
> >> + * 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.
> 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.
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list