On Thu, 10 Dec 2009 18:00:31 +
Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Dec 10, 2009 at 03:49:20PM -0200, Luiz Capitulino wrote:
On Thu, 10 Dec 2009 17:38:13 +
Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Dec 10, 2009 at 02:54:57PM -0200, Luiz Capitulino
Luiz Capitulino wrote:
The list of what libvirt uses is also outdated. In addition to those in
yellow, we also now use, or will likely use in near future
device_add
device_del
info pci
set_link
migrate_cancel
migrate_set_downtime
drive_add
info usb
So given the 0.12 release
Luiz Capitulino wrote:
On Thu, 10 Dec 2009 18:24:38 +0200
Avi Kivity a...@redhat.com wrote:
Let me put it another way, I don't think adding null to the json
parser and incorporating it into this command is a good idea at this
stage in the release so if we want to do something like this, we
Daniel P. Berrange wrote:
Please don't do that. libvirt is adding support for new features all the
time. I don't want to be in the situation where we can't add a new feature
because it is missing in the JSON impl. If we're going to provide a supported
JSON monitor it needs to have all the
On Fri, 11 Dec 2009 07:18:27 -0600
Anthony Liguori aligu...@linux.vnet.ibm.com wrote:
Let's focus on converting the remaining monitor commands. The goal is
that any user of the monitor today can convert over to QMP.
Once we've achieved that goal, let's start looking at introducing proper
On Fri, Dec 11, 2009 at 07:20:12AM -0600, Anthony Liguori wrote:
Daniel P. Berrange wrote:
Please don't do that. libvirt is adding support for new features all the
time. I don't want to be in the situation where we can't add a new feature
because it is missing in the JSON impl. If we're going
On 12/10/2009 06:03 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 12/10/2009 02:56 PM, Anthony Liguori wrote:
I'd prefer an empty dict. I actually prefer that over null.
Depends. Key not present suggests the feature is not implemented.
Value is null suggests the feature is not used.
Avi Kivity wrote:
But we have two null conditions to check for, in an extendible
dictionary:
1. The feature is unknown to qemu
2. The feature is known to qemu, but disabled
So, if 'field' in result: tests the former, and if
result['field']: tests the latter.
In your example, a period of
On 12/10/2009 06:20 PM, Anthony Liguori wrote:
By the same token, wouldn't you probably do:
name = hpet_info.get('name', None)
For name, yes. For an optional feature where you're interested in
knowing both its existence and its value (if it exists), no.
Let me put it another way, I
On Thu, 10 Dec 2009 18:24:38 +0200
Avi Kivity a...@redhat.com wrote:
Let me put it another way, I don't think adding null to the json
parser and incorporating it into this command is a good idea at this
stage in the release so if we want to do something like this, we need
to defer it
On 12/10/2009 06:54 PM, Luiz Capitulino wrote:
On Thu, 10 Dec 2009 18:24:38 +0200
Avi Kivitya...@redhat.com wrote:
Let me put it another way, I don't think adding null to the json
parser and incorporating it into this command is a good idea at this
stage in the release so if we want to do
On Thu, 10 Dec 2009 19:02:37 +0200
Avi Kivity a...@redhat.com wrote:
On 12/10/2009 06:54 PM, Luiz Capitulino wrote:
On Thu, 10 Dec 2009 18:24:38 +0200
Avi Kivitya...@redhat.com wrote:
Let me put it another way, I don't think adding null to the json
parser and incorporating it
On Thu, Dec 10, 2009 at 02:54:57PM -0200, Luiz Capitulino wrote:
On Thu, 10 Dec 2009 18:24:38 +0200
Avi Kivity a...@redhat.com wrote:
Let me put it another way, I don't think adding null to the json
parser and incorporating it into this command is a good idea at this
stage in the
On Thu, 10 Dec 2009 17:38:13 +
Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Dec 10, 2009 at 02:54:57PM -0200, Luiz Capitulino wrote:
An option we have is: libvirt actually uses four or five of those
info commands. So, we could drop all the rest and guarantee that
only those
On Thu, Dec 10, 2009 at 03:49:20PM -0200, Luiz Capitulino wrote:
On Thu, 10 Dec 2009 17:38:13 +
Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Dec 10, 2009 at 02:54:57PM -0200, Luiz Capitulino wrote:
An option we have is: libvirt actually uses four or five of those
info
Luiz Capitulino lcapitul...@redhat.com writes:
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 29 +
1 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index 47f794d..3d33bd8 100644
--- a/monitor.c
+++
On Thu, 10 Dec 2009 11:09:53 +0100
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 29 +
1 files changed, 25 insertions(+), 4 deletions(-)
Luiz Capitulino wrote:
On Thu, 10 Dec 2009 11:09:53 +0100
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 29 +
1 files changed, 25
On 12/10/2009 02:56 PM, Anthony Liguori wrote:
I'd prefer an empty dict. I actually prefer that over null.
Depends. Key not present suggests the feature is not implemented.
Value is null suggests the feature is not used. Both key and value
present suggest the feature is in implemented
On 12/10/2009 05:55 PM, Avi Kivity wrote:
On 12/10/2009 02:56 PM, Anthony Liguori wrote:
I'd prefer an empty dict. I actually prefer that over null.
Depends. Key not present suggests the feature is not implemented.
Value is null suggests the feature is not used. Both key and value
Avi Kivity wrote:
On 12/10/2009 02:56 PM, Anthony Liguori wrote:
I'd prefer an empty dict. I actually prefer that over null.
Depends. Key not present suggests the feature is not implemented.
Value is null suggests the feature is not used. Both key and value
present suggest the feature
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
monitor.c | 29 +
1 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index 47f794d..3d33bd8 100644
--- a/monitor.c
+++ b/monitor.c
@@ -514,10 +514,30 @@ static void
22 matches
Mail list logo
