qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P . Berrangé
Subject: Re: [PATCH 0/5] Stop adding HMP-only commands, allow QMP for all
Date: Wed, 8 Sep 2021 16:24:40 +0100
User-agent: Mutt/2.0.7 (2021-05-04)

On Wed, Sep 08, 2021 at 05:09:13PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > 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,
> 
> Specifics?  QMP command returns a string, HMP wrapper prints that
> string?

yes, a command returning a single opaque printf formatted string would
be the common case.  At a more general POV though, the JSON doc received
by the client should be usable "as received", immediately after JSON
de-serialization without needing any further custom parsing on top.

ie if a value needs to be parsed by the client, then it must be split
into multiple distinct values in the QAPI data type design to remove
the need for parsing by the client. 

If a command's design violates that, then it must remain under the
"x-" prefix.  "info registers" is a example because we're printf
formatting each register value into a opaque string. Any client
needing a specific register value would have to scanf parse this
string. The justification for not representing each register as
a distinct QAPI field is that we don't think machines genuinely
need to parse this, as its just adhoc human operator debug info.
So we take the easy option and just printf to a string and put
it under "x-" prefix



> For many HMP commands, a QMP commands with the same name exists, and the
> former is probably a wrapper around the latter.  Same for HMP "info FOO"
> and QMP query-FOO.
> 
> HMP commands without such a match:
> 
>     boot_set
>     change
>     commit
>     cpu
>     delvm
>     drive_add
>     drive_del
>     exit_preconfig
>     gdbserver
>     gpa2hpa
>     gpa2hva
>     gva2gpa
>     help
>     hostfwd_add
>     hostfwd_remove
>     i
>     info
>     info capture
>     info cmma
>     info cpus
>     info history
>     info ioapic
>     info irq
>     info jit
>     info lapic
>     info mem
>     info mtree
>     info network
>     info numa
>     info opcount
>     info pic
>     info profile
>     info qdm
>     info qom-tree
>     info qtree
>     info ramblock
>     info rdma
>     info registers
>     info roms
>     info skeys
>     info snapshots
>     info sync-profile
>     info tlb
>     info trace-events
>     info usb
>     info usbhost
>     info usernet
>     loadvm
>     log
>     logfile
>     mce
>     migrate_set_capability
>     migrate_set_parameter
>     migration_mode
>     mouse_button
>     mouse_move
>     mouse_set
>     nmi
>     o
>     pcie_aer_inject_error
>     print
>     qemu-io
>     savevm
>     sendkey
>     singlestep
>     snapshot_blkdev
>     snapshot_blkdev_internal
>     snapshot_delete_blkdev_internal
>     stopcapture
>     sum
>     sync-profile
>     trace-event
>     trace-file
>     watchdog_action
>     wavcapture
>     x
>     xp
> 
> This is 77 out of 170 HMP commands.  I was hoping for fewer.

Wow, yes, I'm surprised ! A few of those do indeed have QMP
equivalents, but with slight differences eg savevm ->
snapshot-save, but clearly we have a big list regardless


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]