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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Sep 09, 2021 at 06:48:21AM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > 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. 
> 
> Yes, that's QMP doctrine.
> 
> > 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
> 
> Got it.
> 
> Limitations:
> 
> 1. If we convert a long-running HMP command to this technique, we print
>    its output only after it completed its work.  We also end up with a
>    long-running QMP command, which is bad, because it stops the main
>    loop and makes the QMP monitor unresponsive (except for OOB commands,
>    if the client is careful).  The former can be mitigated with
>    'coroutine': true.  The latter can't.

I'm essentially ignoring this problem because it already exists
in QMP, because anyone needing a HMP-only command today will be
running it via the QMP 'human-monitor-command' and thus have the
behaviour you describe.

> 2. We can't prompt for input.
> 
>    The only current use I can see is HMP "change vnc passwd" prompting
>    for a password.  Except you currently have to say "change vnc passwd
>    wtf" to get it to prompt (suspect logic error in commit cfb5387a1de).

Prompting just needs to be killed off. The VNC code supports the 'secret'
object type now, in the same way as the rest of the QEMU codebase that
needs passwords. So we just need a way to tell VNC the QOM ID of a new
"secret" instance instead.

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 :|