Mark Burton <mark.bur...@greensocs.com> writes: >> 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.
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. [...]
