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 <jto...@redhat.com> Jano
signature.asc
Description: PGP signature
