Re: Redesign of QEMU startup & initial configuration

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 12/13/21 16:28, Markus Armbruster wrote:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>> 
>>> On 12/10/21 14:54, Markus Armbruster wrote:
>>>> I want an open path to a single binary.  Taking years to get there is
>>>> fine.
>>>
>>> The single binary is a distraction in my opinion.  Imagine
>>> instead of vl.c you have this in your second binary:

[...]

>>> This is the ultimate QEMU startup code.  If we can get this code to
>>> actually build a machine, you've reached the point where you don't care
>>> about what is in the command line parser; and consequently you don't care
>>> if there is one binary or two.
>> 
>> Define "you".  Also explain why it should include me, because I think it
>> doesn't :)
>
> Impersonal you. :)

Unfortunate choice of a word.

>> By when can we have this second binary in master?  Opinion, please, not
>> promise.
>
> Define "have":
>
> - a binary that builds
>
> - a binary that builds a bootable guest
>
> - a binary that builds any guest that the current well-maintained
>   targets can build, using a given (but roughly full-featured) subset
>  of options
>
> Estimates for the first are easy (it's in my tree), estimates for the
> second depends on somebody helping (upstreaming -M smp took months 
> between me being busy, reviewers being busy, and releases freezing
> development), estimates for the third are hard.

Thanks.

>> Would you object to me expanding the CLI here to the point where I think
>> we can deprecate the old binary?
>> 
>> If yes, why?
>
> Yes, for two reasons.
>
> First, because there will be usually differences between the command
> lines as mentioned elsewhere in the thread.  qemu-system-* is a good 
> name, but one that is already taken by 15 years of docs using the
> existing command line.

A new CLI is pointless unless there are differences to the old one.

It is unadvisable unless we can eventually retire the old one.

While they coexist, the old binary name should use the old CLI, to
reduce confusion.

> Second, because a command line is really hard to get right as
> complexity increases.  QMP is the way to go to get as clean as
> possible a configuration mechanism.  There *will* be a second set of
> warts layered on top of the above code, and I don't want that.

We do not have consensus.  We may have misunderstandings.

Let's start with where we (hopefully) agree:

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

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

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

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.

* We already layer an interface on top: HMP[2].  It has its warts.

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

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

Objections to these?

[...]


[1] Actually a QEMU character device now, but let's ignore that.

[2] Except where we choose to bypass QMP, but that's unimportant here.