> On 14 Dec 2021, at 12:48, Markus Armbruster <arm...@redhat.com> wrote:
>
> Paolo Bonzini <pbonz...@redhat.com> writes:
>
>> On 12/13/21 16:28, Markus Armbruster wrote:
>>> Paolo Bonzini <pbonz...@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.
For “Completing” the interface, I agree.
To add a certain number of use cases - many of those can be (have been - aka
preconfig) done, if with some degree of unpleasant-ness NOW without full
re-working. That would give us test cases that we can subsequently use to test
against as we move forward.
>
> * 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.
>
(Unless one considers that a ‘human’ and/or ’script’ interface would just be
‘yet another management interface’…. And can/should be relegated to Somebody
Else’s Problem)
Cheers
Mark.
> 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.
>