On Tue, Jul 02, 2013 at 10:20:39AM -0400, Luiz Capitulino wrote:
On Tue, 2 Jul 2013 16:37:29 +0800
Amos Kong ak...@redhat.com wrote:
Btw, I find your approach interesting but I'm wondering if it's going to
be a good thing to keep all the schema in memory. Do you have an idea
on its
On Wed, Jul 03, 2013 at 07:54:47AM -0500, Anthony Liguori wrote:
Paolo Bonzini pbonz...@redhat.com writes:
Il 02/07/2013 22:58, Anthony Liguori ha scritto:
We consume the schema in QEMU. No reason for us to consume it in a
different format than libvirt.
One reason could be that
Am 03.07.2013 um 17:59 hat Anthony Liguori geschrieben:
Kevin Wolf kw...@redhat.com writes:
Am 02.07.2013 um 19:06 hat Anthony Liguori geschrieben:
Eric Blake ebl...@redhat.com writes:
On 07/02/2013 08:51 AM, Anthony Liguori wrote:
Amos Kong ak...@redhat.com writes:
Introduces
Il 03/07/2013 18:06, Anthony Liguori ha scritto:
Paolo Bonzini pbonz...@redhat.com writes:
Il 03/07/2013 14:54, Anthony Liguori ha scritto:
So, qapi-schema.json has to be readable/writable _mostly_ by humans.
That it is valid JSON is little more than a curious accident, because
I can
Il 03/07/2013 17:59, Anthony Liguori ha scritto:
For instance:
{ command: foo,
arguments: { name: str, id: int },
optional: { bar: bool },
defaults: { bar: false } }
This is still not a dictionary that QAPI is able to describe.
Paolo
Paolo Bonzini pbonz...@redhat.com writes:
Il 02/07/2013 22:58, Anthony Liguori ha scritto:
We consume the schema in QEMU. No reason for us to consume it in a
different format than libvirt.
One reason could be that qapi-schema.json, as written, lacks a schema
that can be expressed
Il 03/07/2013 14:54, Anthony Liguori ha scritto:
So, qapi-schema.json has to be readable/writable _mostly_ by humans.
That it is valid JSON is little more than a curious accident, because
I can assure you that it wasn't an accident.
Sure, it is not. But when designing the right API for a
Am 02.07.2013 um 19:06 hat Anthony Liguori geschrieben:
Eric Blake ebl...@redhat.com writes:
On 07/02/2013 08:51 AM, Anthony Liguori wrote:
Amos Kong ak...@redhat.com writes:
Introduces new monitor command to query QMP schema information,
the return data is a nested dict/list, it
Kevin Wolf kw...@redhat.com writes:
Am 02.07.2013 um 19:06 hat Anthony Liguori geschrieben:
Eric Blake ebl...@redhat.com writes:
On 07/02/2013 08:51 AM, Anthony Liguori wrote:
Amos Kong ak...@redhat.com writes:
Introduces new monitor command to query QMP schema information,
the
Paolo Bonzini pbonz...@redhat.com writes:
Il 03/07/2013 14:54, Anthony Liguori ha scritto:
So, qapi-schema.json has to be readable/writable _mostly_ by humans.
That it is valid JSON is little more than a curious accident, because
I can assure you that it wasn't an accident.
Sure, it is
On Tue, Jul 02, 2013 at 01:27:32PM -0500, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com writes:
On 07/02/2013 11:01 AM, Paolo Bonzini wrote:
Arguably that rule of thumb would apply equally to the QEMU
build scripts which already parse qapi-schema.json. It could
be possible to
On Thu, Jun 20, 2013 at 11:20:21PM -0400, Luiz Capitulino wrote:
On Wed, 19 Jun 2013 20:24:37 +0800
Amos Kong ak...@redhat.com wrote:
Introduces new monitor command to query QMP schema information,
the return data is a nested dict/list, it contains the useful
metadata.
Thanks your
On Tue, 2 Jul 2013 16:37:29 +0800
Amos Kong ak...@redhat.com wrote:
Btw, I find your approach interesting but I'm wondering if it's going to
be a good thing to keep all the schema in memory. Do you have an idea
on its size?
The size of qmp_schema_table[] is 1528 bytes.
method 2rd:
Amos Kong ak...@redhat.com writes:
Introduces new monitor command to query QMP schema information,
the return data is a nested dict/list, it contains the useful
metadata.
we can add events definations to qapi-schema.json, then it can
also be queried.
Signed-off-by: Amos Kong
On 07/02/2013 08:51 AM, Anthony Liguori wrote:
Amos Kong ak...@redhat.com writes:
Introduces new monitor command to query QMP schema information,
the return data is a nested dict/list, it contains the useful
metadata.
we can add events definations to qapi-schema.json, then it can
also be
On Tue, Jul 02, 2013 at 09:28:51AM -0600, Eric Blake wrote:
On 07/02/2013 08:51 AM, Anthony Liguori wrote:
Amos Kong ak...@redhat.com writes:
Introduces new monitor command to query QMP schema information,
the return data is a nested dict/list, it contains the useful
metadata.
we
On 06/19/2013 06:49 AM, Amos Kong wrote:
On Wed, Jun 19, 2013 at 08:24:37PM +0800, Amos Kong wrote:
Introduces new monitor command to query QMP schema information,
the return data is a nested dict/list, it contains the useful
metadata.
we can add events definations to qapi-schema.json, then
On 07/02/2013 09:39 AM, Daniel P. Berrange wrote:
Maybe I'm being too meta here, but why not just return qapi-schema.json
as a string and call it as day?
Because qapi-schema.json requires further parsing. For example, how is
a client supposed to know that '*foo':'int' means that there is an
Arguably that rule of thumb would apply equally to the QEMU
build scripts which already parse qapi-schema.json. It could
be possible to normalize qapi-schema.json somewhat to remove
this 2-stage parsing if we went down this route.
Indeed, I wouldn't mind a one-time pass over
Eric Blake ebl...@redhat.com writes:
On 07/02/2013 08:51 AM, Anthony Liguori wrote:
Amos Kong ak...@redhat.com writes:
Introduces new monitor command to query QMP schema information,
the return data is a nested dict/list, it contains the useful
metadata.
we can add events definations to
On 07/02/2013 11:01 AM, Paolo Bonzini wrote:
Arguably that rule of thumb would apply equally to the QEMU
build scripts which already parse qapi-schema.json. It could
be possible to normalize qapi-schema.json somewhat to remove
this 2-stage parsing if we went down this route.
Indeed, I
On 07/02/2013 11:06 AM, Anthony Liguori wrote:
Because qapi-schema.json requires further parsing. For example, how is
a client supposed to know that '*foo':'int' means that there is an
argument named 'foo' but it is optional? The rule of thumb with QMP is
that if you have to post-process
Eric Blake ebl...@redhat.com writes:
On 07/02/2013 09:39 AM, Daniel P. Berrange wrote:
Maybe I'm being too meta here, but why not just return qapi-schema.json
as a string and call it as day?
Because qapi-schema.json requires further parsing. For example, how is
a client supposed to know
Eric Blake ebl...@redhat.com writes:
On 07/02/2013 11:01 AM, Paolo Bonzini wrote:
Arguably that rule of thumb would apply equally to the QEMU
build scripts which already parse qapi-schema.json. It could
be possible to normalize qapi-schema.json somewhat to remove
this 2-stage parsing if we
Eric Blake ebl...@redhat.com writes:
On 07/02/2013 11:06 AM, Anthony Liguori wrote:
Because qapi-schema.json requires further parsing. For example, how is
a client supposed to know that '*foo':'int' means that there is an
argument named 'foo' but it is optional? The rule of thumb with QMP
Il 02/07/2013 20:21, Anthony Liguori ha scritto:
Indeed, I wouldn't mind a one-time pass over qapi-schema.json to make it
follow a more rigid format if that made it easier to use it as-is with
less post-processing. It won't be very nice to backport such a
conversion, but I don't know
On 07/02/2013 02:00 PM, Paolo Bonzini wrote:
Il 02/07/2013 20:21, Anthony Liguori ha scritto:
Indeed, I wouldn't mind a one-time pass over qapi-schema.json to make it
follow a more rigid format if that made it easier to use it as-is with
less post-processing. It won't be very nice to
Paolo Bonzini pbonz...@redhat.com writes:
Il 02/07/2013 20:21, Anthony Liguori ha scritto:
Indeed, I wouldn't mind a one-time pass over qapi-schema.json to make it
follow a more rigid format if that made it easier to use it as-is with
less post-processing. It won't be very nice to
Il 02/07/2013 22:58, Anthony Liguori ha scritto:
We consume the schema in QEMU. No reason for us to consume it in a
different format than libvirt.
One reason could be that qapi-schema.json, as written, lacks a schema
that can be expressed itself using QAPI.
Yup, but how much does
On Wed, 19 Jun 2013 20:24:37 +0800
Amos Kong ak...@redhat.com wrote:
Introduces new monitor command to query QMP schema information,
the return data is a nested dict/list, it contains the useful
metadata.
Thanks for the good work, Amos!
When testing this though I actually get qemu-ga's
Introduces new monitor command to query QMP schema information,
the return data is a nested dict/list, it contains the useful
metadata.
we can add events definations to qapi-schema.json, then it can
also be queried.
Signed-off-by: Amos Kong ak...@redhat.com
---
Makefile | 4 +-
31 matches
Mail list logo
