On 03/10/2011 06:42 PM, Anthony Liguori wrote:
Maybe for QMPv2, but for QMPv1, this is going to introduce an
extremely incompatible change.
Why? It's 100% backwards compatible.
It's a very significant change for clients. While technical
compatible, it would require a change to the client
On 03/10/2011 06:04 PM, Anthony Liguori wrote:
On 03/10/2011 09:45 AM, Avi Kivity wrote:
btw2, I now nominate subscribe and unsubscribe as replacements for
get and put.
Subscribe implies sub/pub in my mind and we're not publishing events
so I don't think it fits the model.
A pub/sub
On 03/12/2011 02:42 PM, Avi Kivity wrote:
On 03/10/2011 06:04 PM, Anthony Liguori wrote:
On 03/10/2011 09:45 AM, Avi Kivity wrote:
btw2, I now nominate subscribe and unsubscribe as replacements for
get and put.
Subscribe implies sub/pub in my mind and we're not publishing
events so I
On 03/10/2011 06:39 AM, Avi Kivity wrote:
What I mean is that the client should specify the handle, like it does
for everything else it gives a name (netdevs, blockdevs, SCM_RIGHT
fds, etc).
{ execute: listen-event, arguments: { event: blah, id: blah1 } }
{ execute: unlisten-event
On 03/10/2011 04:12 PM, Anthony Liguori wrote:
On 03/10/2011 06:39 AM, Avi Kivity wrote:
What I mean is that the client should specify the handle, like it
does for everything else it gives a name (netdevs, blockdevs,
SCM_RIGHT fds, etc).
{ execute: listen-event, arguments: { event: blah,
On 03/10/2011 04:24 PM, Avi Kivity wrote:
What would the wire exchange look like?
{ 'execute': 'get-block-io-error-event' }
{ 'return' : 32 }
...
{ 'event': 'BLOCK_IO_ERROR', 'data': { 'action': 'stop', 'device':
'ide0-hd0', 'operation': 'read' }, 'tag': 32 }
...
{ 'execute':
On 03/10/2011 08:24 AM, Avi Kivity wrote:
On 03/10/2011 04:12 PM, Anthony Liguori wrote:
On 03/10/2011 06:39 AM, Avi Kivity wrote:
What I mean is that the client should specify the handle, like it
does for everything else it gives a name (netdevs, blockdevs,
SCM_RIGHT fds, etc).
{
On 03/10/2011 09:30 AM, Avi Kivity wrote:
On 03/10/2011 04:24 PM, Avi Kivity wrote:
What would the wire exchange look like?
{ 'execute': 'get-block-io-error-event' }
{ 'return' : 32 }
...
{ 'event': 'BLOCK_IO_ERROR', 'data': { 'action': 'stop', 'device':
'ide0-hd0', 'operation': 'read' },
On 03/10/2011 05:33 PM, Anthony Liguori wrote:
We pretty much need to keep the QEMU signature the same. That would
mean an internal signature of:
BlockIoErrorEvent *qmp_connect_block_io_error_event(Error **errp)
{
}
So the marshal function would then need to do something like:
void
On 03/10/2011 05:41 PM, Anthony Liguori wrote:
I also think it should be at the protocol layer:
{ execute: some-command, id: foo, arguments: { ... } }
{ result: { ... }, id: foo }
{ subscribe: block-io-error, id: bar, arguments: { ... } }
{ result: { ... } id: bar }
{ event:
On 03/10/2011 09:45 AM, Avi Kivity wrote:
btw2, I now nominate subscribe and unsubscribe as replacements for
get and put.
Subscribe implies sub/pub in my mind and we're not publishing events
so I don't think it fits the model.
A pub/sub event model would be interesting to think through
On 03/10/2011 09:49 AM, Avi Kivity wrote:
On 03/10/2011 05:41 PM, Anthony Liguori wrote:
I also think it should be at the protocol layer:
{ execute: some-command, id: foo, arguments: { ... } }
{ result: { ... }, id: foo }
{ subscribe: block-io-error, id: bar, arguments: { ... } }
{ result:
This is needed for libqmp to support events. put-event is used to disconnect
from signals.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
diff --git a/qmp-schema.json b/qmp-schema.json
index 3f2dd4e..a13885f 100644
--- a/qmp-schema.json
+++ b/qmp-schema.json
@@ -58,3 +58,18 @@
# Since:
13 matches
Mail list logo
