Re: [PATCH 0/5] Stop adding HMP-only commands, allow QMP for all

["Ján Tomko" <jtomko@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3479 bytes --]

On a Wednesday in 2021, Daniel P. Berrangé wrote:
>We are still adding HMP commands without any QMP counterparts. This is
>done because there are a reasonable number of scenarios where the cost
>of designing a QAPI data type for the command is not justified.
>
>This has the downside, however, that we will never be able to fully
>isolate the monitor code from the remainder of QEMU internals. It is
>desirable to be able to get to a point where subsystems in QEMU are
>exclusively implemented using QAPI types and never need to have any
>knowledge of the monitor APIs.
>
>The way to get there is to stop adding commands to HMP only. All
>commands must be implemented using QMP, and any HMP implementation
>be a shim around the QMP implementation.
>
>We don't want to compromise our supportability of QMP long term though.
>
>This series proposes that we relax our requirements around fine grained
>QAPI data design, but with the caveat that any command taking this
>design approach is mandated to use the 'x-' name prefix.
>
>This tradeoff should be suitable for any commands we have been adding
>exclusively to HMP in recent times, and thus mean we have mandate QMP
>support for all new commands going forward.
>
>This series illustrates the concept by converting the "info registers"
>HMP to invoke a new 'x-query-registers' QMP command. Note that only
>the i386 CPU target is converted to work with this new approach, so
>this series needs to be considered incomplete. If we go forward with
>this idea, then a subsequent version of this series would need to
>obviously convert all other CPU targets.
>
>After doing that conversion the only use of qemu_fprintf() would be
>the disas.c file. Remaining uses of qemu_fprintf and qemu_printf
>could be tackled in a similar way and eventually eliminate the need
>for any of these printf wrappers in QEMU.
>
>NB: I added docs to devel/writing-qmp-commands.rst about the two
>design approaches to QMP. I didn't see another good place to put
>an explicit note that we will not add any more HMP-only commands.
>Obviously HMP/QMP maintainers control this in their reviews of
>patches, and maybe that's sufficient ?
>
>NB: if we take this approach we'll want to figure out how many
>HMP-only commands we actually have left and then perhaps have
>a task to track their conversion to QMP. This could possibly
>be a useful task for newbies if we make it clear that they
>wouldn't be required to undertake complex QAPI modelling in
>doing this conversion.
>
>Daniel P. Berrangé (5):
>  docs/devel: document expectations for QAPI data modelling for QMP
>  hw/core: introduce 'format_state' callback to replace 'dump_state'
>  target/i386: convert to use format_state instead of dump_state
>  qapi: introduce x-query-registers QMP command
>  monitor: rewrite 'info registers' in terms of 'x-query-registers'
>
> docs/devel/writing-qmp-commands.rst |  25 +++
> hw/core/cpu-common.c                |  15 ++
> hw/core/machine-qmp-cmds.c          |  28 +++
> include/hw/core/cpu.h               |  13 +-
> monitor/misc.c                      |  25 ++-
> qapi/machine.json                   |  37 ++++
> target/i386/cpu-dump.c              | 325 +++++++++++++++-------------
> target/i386/cpu.c                   |   2 +-
> target/i386/cpu.h                   |   2 +-
> 9 files changed, 307 insertions(+), 165 deletions(-)
>

Reviewed-by: Ján Tomko <jtomko@redhat.com>

Jano

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]