Re: Redesign of QEMU startup & initial configuration

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> 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.

In my opinion, the worst mess is the reordering and the (commonly
unstated, sometimes unknown) dependencies that govern it.

The reordering is part of the stable interface.  Its finer points
basically nobody understands, at least not without staring at the code.

When we mess with the order, we commonly break things.

This is what leads me to my "still a mess" and "impractical" verdicts.

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

Practical ideas on fixing it?

>> * 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.

I'm not sure I got this.

>> 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.

Yes, a trivial CLI transport alone may not suffice to retire the old
CLI.  By itself, that doesn't mean trivial transports must be avoided.

Do I have to argue the benefits of a trivial configuration file
transport?

Do I have to argue the benefits of a trivial CLI transport for use by
relatively unsophisticated programs / relatively sophisticated humans
(such as developers)?

Can we agree these benefits are not zero?

If yes, we can move on to debate whether such trivial transports are
worth their (modest) keep.

> 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.

I assure you that bad QMP is plenty hard to deprecate, even when libvirt
can be updated to cope.

I think HMP is easier to change than QMP and CLI mostly because we've
spent years guiding people in need of a stable interface towards QMP.

>> * 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.

The issues with the CLI will still influence its users.

Can we agree that human users deserve something better than the current
CLI?

If no, then I doubt consensus is possible.

If yes, then we need to discuss how to build a better CLI for humans.
No "somebody could" cop outs, please.

I think we can learn from our experience with HMP/QMP.

Good:

* Separate interfaces for machines and for humans, because their needs
  are different: QMP and HMP.

* The stable interface is clear: QMP unless explicitly marked unstable.

* Layering the human interface on top of the machine interface: HMP
  commands implemented on top of QMP's internal C interface.

Bad:

* Not layering the human interface on top of the machine interface: HMP
  commands bypassing QMP's internal C interface.

* Proper layering is too much work: writing HMP commands that way should
  be easier, not harder.

Debatable:

* Some functionality is only available in HMP, mostly because that's
  less work.  Can't really argue against "this is more trouble than it's
  worth".

* Some functionality is only available in QMP, mostly because providing
  equivalent HMP commands is too much work.  Sometimes, equivalent HMP
  commands are awkwardly low level for humans, but "nope, go use QMP" is
  at least as awkward.

There's obviously more, but I think these are the points that matter
here.

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