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 wrote:
> >>> External QOM interfaces have their place, especially for debugging or
> >>> trying out things before there is a proper API, but it's
Il 25/02/2014 11:15, Stefan Hajnoczi ha scritto:
On Tue, Feb 25, 2014 at 10:46 AM, Kevin Wolf 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.
-obje
On Tue, Feb 25, 2014 at 10:46 AM, Kevin Wolf 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
Am 21.02.2014 um 15:32 hat Stefan Hajnoczi geschrieben:
> On Fri, Feb 21, 2014 at 10:16 AM, Stefan Hajnoczi 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 myse
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
Am 25.02.2014 09:25, schrieb Markus Armbruster:
> Eric Blake 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,
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
Eric Blake 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 com
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
Eric Blake 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 havi
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. S
Il 21/02/2014 15:29, Anthony Liguori ha scritto:
On Fri, Feb 21, 2014 at 1:16 AM, Stefan Hajnoczi 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
On Fri, Feb 21, 2014 at 10:16 AM, Stefan Hajnoczi 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. Thanks Paolo, Mar
On Fri, Feb 21, 2014 at 1:16 AM, Stefan Hajnoczi 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 command:
> *
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
15 matches
Mail list logo
