[Top][All Lists]

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

Re: [Qemu-devel] your mail

From: Eric Blake
Subject: Re: [Qemu-devel] your mail
Date: Thu, 28 Jun 2018 06:51:38 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 06/28/2018 03:31 AM, Markus Armbruster wrote:
Peter Xu <address@hidden> writes:

On Tue, Jun 26, 2018 at 07:21:49PM +0200, Markus Armbruster wrote:
I fooled around a bit, and I think there are a few lose ends.
Talking to a QMP monitor that supports OOB:

     $ socat UNIX:test-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
     {"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2}, "package": 
"v2.12.0-1703-gb909799463"}, "capabilities": ["oob"]}}
     QMP> { "execute": "qmp_capabilities", "arguments": { "oob": true } }
     {"error": {"class": "GenericError", "desc": "Parameter 'oob' is 
     QMP> { "execute": "qmp_capabilities", "arguments": { "enable": ["oob"] } }
     {"return": {}}
     QMP> { "execute": "query-qmp-schema" }
     {"error": {"class": "GenericError", "desc": "Out-Of-Band capability requires 
that every command contains an 'id' field"}}

Why does every command require 'id'?

Why am I asking?  Requiring 'id' is rather onerous when you play with
QMP by hand.

Possible solutions other than requiring "id":

1. Make out-of-band responses recognizable

    Just like we copy "id" to the response, we could copy "run-oob", or
    maybe "control".

    Solves the "match response to command" problem, doesn't solve the
    "match COMMAND_DROPPED event to command" problem.

    Permit me a digression.  "control": { "run-oob": true } is awfully
    verbose.  Back when we hashed out the OOB design, I proposed to use
    "exec-oob" instead of "execute" to run a command OOB.  I missed when
    that morphed into flag "run-oob" wrapped in object "control".  Was it
    in response to reviewer feedback?  Can you give me a pointer?

It's not too late to change back. Since OOB is still new to 3.0, we could indeed go with a shorter invocation of 'exec-oob' (and I'd actually be in favor of such a change).

    The counterpart to "exec-oob" would be "return-oob" and "error-oob".

In other words, the change in the keyword of the response will let you know that it is replying to the most recent oob command. This works well if we guarantee that we never have more than one unprocessed oob command in the pipeline at a time; but fails if oob commands can be threaded against one another and start replying in a different order than original submission. Or, we could state that if you use 'exec-oob', then 'id' is mandatory (and 'id' in the 'return' or 'error' is then sufficient to tie it back); but when using plain 'execute', 'id' remains optional.

2. Do nothing; it's the client's problem

    If the client needs to match responses and events to commands, it
    should use the feature that was expressly designed for helping with
    that: "id".

    Note that QMP's initial design assumed asynchronous commands,
    i.e. respones that may arrive in any order.  Nevertheless, it did not
    require "id".  Same reasoning: if the client needs to match, it can
    use "id".

As so often when "do nothing" is a viable solution, it looks mighty
attractive to me :)

Indeed, although the documentation should still be explicit on recommending the use of 'id' when oob is enabled.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

reply via email to

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