Re: [Qemu-devel] Proposal for extensions of block job commands in QEMU 1.2

[Paolo Bonzini <pbonzini@redhat.com>]

Il 21/05/2012 17:44, Anthony Liguori ha scritto:
> It also gets very challenging if some options are backported and others
> aren't.

It gets challenging anyway with backports.  If qmp_block_stream_v1_2
knows of defaults and doesn't send them on the wire, it will work if you
only rely on the subset of options that was backported.  If it doesn't,
downstreams will have to use vendor namespaces.

> I guess let me ask the following question:
> 
> Is the problem that should have an 'options' parameter to this command? 
> Do we anticipate future addition of arguments?

First of all, streaming works nicely as it is.  It is nice to make
things work similarly for streaming and mirroring, but not paramount.

Regarding the latter question: perhaps, but then where do you draw the
line?  Is it okay to add new kinds of data to unions?  (Besides, unions
are quite heavyweight to use in the JSON, and if I wanted to have an
"options" array of unions I would like to put the speed in there too.
So the boat has sailed).

> If we can at least minimize the C API breakages, I'd be happy.

My opinion is this: your goal makes sense, but it is not 100% practical
yet because:

1) we're still far enough from being feature complete (in comparison to
a certain proprietary product that does sport some extra bullets in its
marketing brochures).

2) we don't have a C API, and we don't know how it would look like (e.g.
would it use gio? or libev? or...).  It's good to be in the right
mindset from the beginning, but minimizing changes to hmp.c is by itself
not a particularly useful goal.

Paolo