qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH 0/5] Stop adding HMP-only commands, allow QMP for all
Date: Wed, 8 Sep 2021 16:24:40 +0100	[thread overview]
Message-ID: <YTjVuEg+wlKPHkAi@redhat.com> (raw)
In-Reply-To: <875yvbrtnq.fsf@dusky.pond.sub.org>

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	other threads:[~2021-09-08 15:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08 10:37 [PATCH 0/5] Stop adding HMP-only commands, allow QMP for all Daniel P. Berrangé
2021-09-08 10:37 ` [PATCH 1/5] docs/devel: document expectations for QAPI data modelling for QMP Daniel P. Berrangé
2021-09-08 17:42   ` Eric Blake
2021-09-09  9:33   ` Markus Armbruster
2021-09-10 12:46     ` Daniel P. Berrangé
2021-09-10 13:45       ` Markus Armbruster
2021-09-10 13:52         ` Daniel P. Berrangé
2021-09-08 10:37 ` [PATCH 2/5] hw/core: introduce 'format_state' callback to replace 'dump_state' Daniel P. Berrangé
2021-09-08 10:37 ` [PATCH 3/5] target/i386: convert to use format_state instead of dump_state Daniel P. Berrangé
2021-09-08 12:17   ` Ján Tomko
2021-09-08 18:05   ` Eric Blake
2021-09-08 22:06     ` Daniel P. Berrangé
2021-09-09  9:55       ` Daniel P. Berrangé
2021-09-08 10:37 ` [PATCH 4/5] qapi: introduce x-query-registers QMP command Daniel P. Berrangé
2021-09-08 18:06   ` Eric Blake
2021-09-09  9:05   ` Markus Armbruster
2021-09-09 10:01     ` Daniel P. Berrangé
2021-09-08 10:37 ` [PATCH 5/5] monitor: rewrite 'info registers' in terms of 'x-query-registers' Daniel P. Berrangé
2021-09-08 11:01   ` Philippe Mathieu-Daudé
2021-09-08 11:02     ` Daniel P. Berrangé
2021-09-08 12:18 ` [PATCH 0/5] Stop adding HMP-only commands, allow QMP for all Ján Tomko
2021-09-08 15:09 ` Markus Armbruster
2021-09-08 15:24   ` Daniel P. Berrangé [this message]
2021-09-09  4:48     ` Markus Armbruster
2021-09-09  8:13       ` Markus Armbruster
2021-09-09  8:40       ` Daniel P. Berrangé
2021-09-08 16:15   ` Philippe Mathieu-Daudé
2021-09-09  6:15   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YTjVuEg+wlKPHkAi@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).