FWIW I Agree.
(Which probably means somethings hiding somewhere :-) ) Cheers Mark. > On 15 Dec 2021, at 21:00, Paolo Bonzini <pbonz...@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.
