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 don't
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 event
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 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: { ... } }
< { resu
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 but
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: block-io-e
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 qmp_mar
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 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).
{ execute:
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': 'put-eve
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, id
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 argu
On 03/09/2011 04:26 PM, Anthony Liguori wrote:
On 03/09/2011 07:58 AM, Avi Kivity wrote:
On 03/09/2011 03:48 PM, Anthony Liguori wrote:
+[ 'put-event', {'tag': 'int'}, {}, 'none' ]
Why is tag an int?
+##
It's a handle so the type doesn't matter as long as I can make sure
values are unique.
On 03/09/2011 07:58 AM, Avi Kivity wrote:
On 03/09/2011 03:48 PM, Anthony Liguori wrote:
+[ 'put-event', {'tag': 'int'}, {}, 'none' ]
Why is tag an int?
+##
It's a handle so the type doesn't matter as long as I can make sure
values are unique. ints are easier to work with because they don'
On 03/09/2011 03:48 PM, Anthony Liguori wrote:
+[ 'put-event', {'tag': 'int'}, {}, 'none' ]
Why is tag an int?
+##
It's a handle so the type doesn't matter as long as I can make sure
values are unique. ints are easier to work with because they don't
require memory allocation.
I think it'
On 03/09/2011 07:31 AM, Avi Kivity wrote:
On 03/07/2011 03:23 AM, Anthony Liguori wrote:
This is needed for libqmp to support events. put-event is used to
disconnect
from signals.
Signed-off-by: Anthony Liguori
diff --git a/qmp-schema.json b/qmp-schema.json
index 3f2dd4e..a13885f 100644
---
On 03/07/2011 03:23 AM, Anthony Liguori wrote:
This is needed for libqmp to support events. put-event is used to disconnect
from signals.
Signed-off-by: Anthony Liguori
diff --git a/qmp-schema.json b/qmp-schema.json
index 3f2dd4e..a13885f 100644
--- a/qmp-schema.json
+++ b/qmp-schema.json
@@ -
This is needed for libqmp to support events. put-event is used to disconnect
from signals.
Signed-off-by: Anthony Liguori
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: 0.14.0
##
[ 'qmp_capa
18 matches
Mail list logo
