Eric Blake ebl...@redhat.com writes:
On 02/24/2014 01:29 AM, Markus Armbruster wrote:
The other burden is documenting what QOM paths to be queried, and
knowing where to find that documentation. That is, it's another layer
of complexity, but it's also a more powerful expression.
I'm
Am 25.02.2014 09:25, schrieb Markus Armbruster:
Eric Blake ebl...@redhat.com writes:
On 02/24/2014 01:29 AM, Markus Armbruster wrote:
The other burden is documenting what QOM paths to be queried, and
knowing where to find that documentation. That is, it's another layer
of complexity, but
Il 25/02/2014 09:25, Markus Armbruster ha scritto:
Haven't we already done that in the past? For example, object-add
currently takes an unspecified dictionary of options, where you would
have to consult QOM documentation to learn what makes sense to send.
My question isn't about where the
Am 25.02.2014 09:30, schrieb Paolo Bonzini:
Il 25/02/2014 09:25, Markus Armbruster ha scritto:
Haven't we already done that in the past? For example, object-add
currently takes an unspecified dictionary of options, where you would
have to consult QOM documentation to learn what makes sense
Am 21.02.2014 um 15:32 hat Stefan Hajnoczi geschrieben:
On Fri, Feb 21, 2014 at 10:16 AM, Stefan Hajnoczi stefa...@redhat.com wrote:
Maybe I just need some convincing but it seems that QAPI is the simplest
and cleanest way to define external APIs.
Disagree? Tell me why :).
I'm
On Tue, Feb 25, 2014 at 10:46 AM, Kevin Wolf kw...@redhat.com wrote:
External QOM interfaces have their place, especially for debugging or
trying out things before there is a proper API, but it's not as the
primary external interface.
Yes, I agree.
Stefan
Il 25/02/2014 11:15, Stefan Hajnoczi ha scritto:
On Tue, Feb 25, 2014 at 10:46 AM, Kevin Wolf kw...@redhat.com wrote:
External QOM interfaces have their place, especially for debugging or
trying out things before there is a proper API, but it's not as the
primary external interface.
Yes, I
Am 25.02.2014 um 11:47 hat Paolo Bonzini geschrieben:
Il 25/02/2014 11:15, Stefan Hajnoczi ha scritto:
On Tue, Feb 25, 2014 at 10:46 AM, Kevin Wolf kw...@redhat.com wrote:
External QOM interfaces have their place, especially for debugging or
trying out things before there is a proper API,
Eric Blake ebl...@redhat.com writes:
On 02/21/2014 07:37 AM, Paolo Bonzini wrote:
I have no objection to introducing a QMP command.
I think qom-find-objects-by-class is a reasonable approach but I would
also consider just grouping all of the IOThreads in a well known path
instead of just
On 02/24/2014 01:29 AM, Markus Armbruster wrote:
The other burden is documenting what QOM paths to be queried, and
knowing where to find that documentation. That is, it's another layer
of complexity, but it's also a more powerful expression.
I'm comparing this situation somewhat to
I need to add a QMP API that lists dataplane threads. This is similar
to query-cpus where the thread IDs are reported. It allows the client
to bind threads to host CPUs.
I'm inclined to add a query-iothreads QMP command:
* It's easy to implement using QAPI
* We've developed best practices for
On Fri, Feb 21, 2014 at 1:16 AM, Stefan Hajnoczi stefa...@redhat.com wrote:
I need to add a QMP API that lists dataplane threads. This is similar
to query-cpus where the thread IDs are reported. It allows the client
to bind threads to host CPUs.
I'm inclined to add a query-iothreads QMP
On Fri, Feb 21, 2014 at 10:16 AM, Stefan Hajnoczi stefa...@redhat.com wrote:
Maybe I just need some convincing but it seems that QAPI is the simplest
and cleanest way to define external APIs.
Disagree? Tell me why :).
I'm replying to myself because we had an interesting discussion on
IRC.
Il 21/02/2014 15:29, Anthony Liguori ha scritto:
On Fri, Feb 21, 2014 at 1:16 AM, Stefan Hajnoczi stefa...@redhat.com wrote:
I need to add a QMP API that lists dataplane threads. This is similar
to query-cpus where the thread IDs are reported. It allows the client
to bind threads to host
On 02/21/2014 07:37 AM, Paolo Bonzini wrote:
I have no objection to introducing a QMP command.
I think qom-find-objects-by-class is a reasonable approach but I would
also consider just grouping all of the IOThreads in a well known path
instead of just having them live in /objects. So
15 matches
Mail list logo
