Re: Summary of Re: Making QEMU easier for management tools and applications

[Paolo Bonzini]

On 10/02/20 11:56, Stefan Hajnoczi wrote:
> On Tue, Feb 4, 2020 at 3:54 PM Markus Armbruster <address@hidden> wrote:
>> = Ways to provide machine-friendly initial configuration =
>>
>> Two ways to provide machine-friendly initial configuration on par with
>> QMP have been proposed:
>>
>> 1. Extend QMP
>>
>>    Machines use the CLI only to configure a QMP socket.  The remainder
>>    of the CLI becomes human-only, with much relaxed compatibility rules.
>>
>> 2. QAPIfy the CLI
>>
>>    Provide a machine-friendly CLI based on QAPI and JSON.  The current
>>    CLI becomes human-only, with much relaxed compatibility rules.
> 
> Do we keep the existing CLI around in both cases?  I'm concerned that
> we're still following the HMP/QMP approach, which has left QEMU with
> the legacy HMP monitor that we still haven't removed.
> 
> I'm in favor of simplifying QEMU at the expense of an incompatible CLI
> change in QEMU 6.0.
> 
> A project like this could prototype incompatible CLI changes in a
> separate git tree.  If it achieves the desired unification (CLI, QMP,
> configuration file) and simplification (less code, legacy removal)
> then it can be merged for an upcoming QEMU major release.

I think Daniel had a good point in suggesting a (possibly) throwaway
fork for either (1) or (2).  Let's see what kind of change is needed to
do 100% QMP-based configuration of guests (or at least to QMP-ify
configuration of devices and backends---things that can already have an
*-add command now); then we can figure out which subset of the current
CLI can be mapped to it.

Paolo