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(-)
signature.asc