Re: Redesign of QEMU startup & initial configuration

[Mark Burton <mark.burton@greensocs.com>]

FWIW I Agree.

(Which probably means somethings hiding somewhere :-) )

Cheers
Mark.

> On 15 Dec 2021, at 21:00, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> 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.