On 10/02/20 11:56, Stefan Hajnoczi wrote: > On Tue, Feb 4, 2020 at 3:54 PM Markus Armbruster <arm...@redhat.com> wrote: >> = Ways to provide machine-friendly initial configuration = >> >> Two ways to provide machine-friendly initial configuration on par with >> QMP have been proposed: >> >> 1. Extend QMP >> >> Machines use the CLI only to configure a QMP socket. The remainder >> of the CLI becomes human-only, with much relaxed compatibility rules. >> >> 2. QAPIfy the CLI >> >> Provide a machine-friendly CLI based on QAPI and JSON. The current >> CLI becomes human-only, with much relaxed compatibility rules. > > Do we keep the existing CLI around in both cases? I'm concerned that > we're still following the HMP/QMP approach, which has left QEMU with > the legacy HMP monitor that we still haven't removed. > > I'm in favor of simplifying QEMU at the expense of an incompatible CLI > change in QEMU 6.0. > > A project like this could prototype incompatible CLI changes in a > separate git tree. If it achieves the desired unification (CLI, QMP, > configuration file) and simplification (less code, legacy removal) > then it can be merged for an upcoming QEMU major release.
I think Daniel had a good point in suggesting a (possibly) throwaway fork for either (1) or (2). Let's see what kind of change is needed to do 100% QMP-based configuration of guests (or at least to QMP-ify configuration of devices and backends---things that can already have an *-add command now); then we can figure out which subset of the current CLI can be mapped to it. Paolo