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. > > Lets update the examples in docs/interop/qmp-spec.txt to show the > current greeting (section 3.1) and how to accept a capability (section > 3.2). The capability negotiation documentation could use some polish. > I'll post a patch.
Thanks for doing that! > > 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 > unexpected"}} > 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'? The COMMAND_DROPPED event is one reason, as you mentioned in the other thread. Meanwhile as long as we have OOB command it means that we can have more than one commands running in parallel, then it's a must that we can mark that out in the response to mark out which command we are replying to. > > Talking to a QMP monitor that doesn't support OOB: > > {"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2}, > "package": "v2.12.0-1703-gb909799463"}, "capabilities": []}} > QMP> { "execute": "qmp_capabilities", "arguments": { "enable": ["oob"] } } > {"error": {"class": "GenericError", "desc": "This monitor does not > support Out-Of-Band (OOB)"}} > QMP> { "execute": "qmp_capabilities" } > {"return": {}} > QMP> { "execute": "query-kvm" } > {"return": {"enabled": true, "present": true}} > QMP> { "execute": "query-kvm", "control": { "run-oob": true } } > {"error": {"class": "GenericError", "desc": "Please enable Out-Of-Band > first for the session during capabilities negotiation"}} > > Telling people to enable OOB when that cannot be done is suboptimal. > More so when it cannot be used here anyway. I'll post a patch. Thanks again! -- Peter Xu