[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redesign of QEMU startup & initial configuration
From: |
Markus Armbruster |
Subject: |
Re: Redesign of QEMU startup & initial configuration |
Date: |
Tue, 14 Dec 2021 15:54:06 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Mark Burton <mark.burton@greensocs.com> writes:
>> On 14 Dec 2021, at 12:48, Markus Armbruster <armbru@redhat.com> wrote:
>>
>> 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.
>
> 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.
I'd be okay with hacking up the current mess some more so it can serve
as a test bed, as long as we all understand that the hacks are to be
reverted.
>> * 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)
I really hate relying on this Somebody guy, he never gets anything done.
[...]
- Re: Redesign of QEMU startup & initial configuration, (continued)
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/13
- Meeting today?, Mark Burton, 2021/12/14
- Re: Meeting today?, Markus Armbruster, 2021/12/14
- Re: Meeting today?, Mark Burton, 2021/12/14
- Re: Meeting today?, Daniel P . Berrangé, 2021/12/14
- Re: Meeting today?, Markus Armbruster, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/15
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/15
- Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration, Mark Burton, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration,
Markus Armbruster <=
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/15
- Re: Redesign of QEMU startup & initial configuration, Mark Burton, 2021/12/15
- Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/16
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/16
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/16
- Re: Redesign of QEMU startup & initial configuration, Mark Burton, 2021/12/16
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/16
- Re: Redesign of QEMU startup & initial configuration, Mark Burton, 2021/12/16
- Re: Redesign of QEMU startup & initial configuration, Damien Hedde, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/13