Re: Redesign of QEMU startup & initial configuration

[Paolo Bonzini]

On 12/14/21 12:48, Markus Armbruster wrote:
> Let's start with where we (hopefully) agree:

More or less I do agree with this, except for a couple points below 
where I think we disagree.

> * We need a single, cohesive, low-level interface suitable for
>    management applications.
>
> * The existing interface is specified in QAPI.  Its concrete transport
>    is QMP.
>
> * The existing interface is not complete: certain things can only be
>    done with the CLI.
>
> * The existing transport is not available early enough to permit
>    completing the interface.

So far so good.

> * Fixing that involves a rework of startup.
> * Reworking the existing startup and managing incompatible changes is
>    impractical, and likely to make the mess we have on our hands worse.

Not really, in particular the startup has been mostly reworked already 
and I disagree that it is messy.  softmmu/vl.c is messy, sure: it has N 
different command line parser for command line options, magic related to 
default devices, and complicated ordering of -object creation.

But the building of emulator data structures is not messy; only the code 
that transforms the user's instructions into startup commands.  The 
messy parts are almost entirely contained within softmmu/vl.c.

The one (and important, but fixable) exception is backends for on-board 
devices: serial_hd, drive_get, and nd_table.

> * A new binary sidesteps the need to manage incompatible change.

More precisely, a new binary sidesteps the need to integrate an existing 
mechanism with a new transport, and deal with the incompatibilities that 
arise.

> Any objections so far?
>
> Now let me make a few more points:
>
> * Single, cohesive interface does not require single transport.  In
>    fact, we already have two: QMP and the (internal) C interface.
>
> * QMP encodes the abstract interface in JSON, and offers the result on a
>    Unix domain socket[1].
>
> * The (internal) C interface encodes the abstract interface as a set of
>    C data types and functions.
>
> * Consider a configuration file transport that encodes the abstract
>    interface in JSON.  The only wart this adds is syntax that is
>    arguiably ill-suited to the purpose.  More suitable syntax exists.
>
> * Similar for CLI.
>
> * To get a "a second set of warts layered on top", we actually have to
>    layer something on top that isn't utterly trivial.  Like a
>    higher-level interface.  The "second set of warts" objection does not
>    apply to (sane) transports.

The problem is that CLI and HMP, being targeted to humans (and as you 
say below humans matter), are not necessarily trivial transports.  If 
people find the trivial transport unusable, we will not be able to 
retire the old CLI.

Bad CLI is also very hard to deprecate because, unlike QMP (for which 
you can delegate the workarounds to Libvirt & friends) and HMP (for 
which people can just learn the new thing and type it), it is baked in 
countless scripts.  People hate it when scripts break.

> * The old CLI is partly layered on QMP, partly on HMP, and partly on
>    internal C interfaces.  It's full of warts.

I've worked on moving it more towards QMP or at least QOM, and much less 
on internal C interfaces.  It still has warts but they are 
self-contained and due to the baroque ordering of options.  My point is 
that we can continue this work to the point that having separate entry 
points (one CLI-centered, one QMP-only) is not a problem.

The issues with the CLI then can be completely self-contained within 
softmmu/vl.c, and will not influence the innards of QEMU.

Paolo

> * Management applications are not the only users that matter.  Humans
>    matter.  Simple programs like ad hoc scripts matter.