Re: KVM call for agenda for 2020-10-06

[Paolo Bonzini <pbonzini@redhat.com>]

On 08/10/20 13:25, Markus Armbruster wrote:
> CLI, config file and QMP are differently convenient for different use
> cases. [...]
> 
> If we could afford just one of the three, we'd probably want to pick
> QMP, because it's the most flexible (it's supports queries naturally),
> and because picking something else can't eliminate QMP.  Fortunately, we
> don't have to pick just one if we base on initial configuration on QAPI.

On the other hand, we don't have to pick just one because we already
have a CLI (though one that is full of warts) so the question is not
whether we want to have a CLI, but whether we want to have a *second* CLI.

So my point is essentially that:

* as you said, you cannot get rid of QMP

* we can make the existing CLI a QMP wrapper just like we did with HMP

* any work on QMP-based configuration would apply just as well to both
binaries, so developers could still mix CLI+QMP when (or if) desirable

* once you have a (warty but well-known) CLI and QMP, there are
diminishing returns in going all the way down to QAPI even for the two
hardest commands (device-add and object-add).  That time is better
invested in minimizing the differences between the two binaries, because
we all know that you won't pry the qemu-system-* command line from the
cold dead hands of users and developers.

(not coincidentially, this goes from least to most controversial).

Of course you may say this is "whataboutism", on the other hand time is
limited so I prefer to make the interesting tasks clear from the
beginning and allow better collaboration.

> I'd like to take a serious swing at QAPIfying them, with a loose schema.

What do you mean by "loose schema"?  Is it anything other than
"represent a QDict with a QAPI list of key-value pairs"?

Paolo

> Good enough for QAPI-based initial configuration interfaces.  Not good
> enough for introspection, but a better QOM introspection could fill that
> gap.
>