[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redesign of QEMU startup & initial configuration
From: |
Mark Burton |
Subject: |
Re: Redesign of QEMU startup & initial configuration |
Date: |
Wed, 15 Dec 2021 21:14:44 +0100 |
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.
- Re: Meeting today?, (continued)
- 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, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/15
- Re: Redesign of QEMU startup & initial configuration,
Mark Burton <=
- 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