Re: [Qemu-devel] QOM vs QAPI for QMP APIs

[Paolo Bonzini <pbonzini@redhat.com>]

Il 21/02/2014 15:29, Anthony Liguori ha scritto:
> On Fri, Feb 21, 2014 at 1:16 AM, Stefan Hajnoczi <stefanha@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 command:
>>  * It's easy to implement using QAPI
>>  * We've developed best practices for QMP APIs
>>  * We know how to version and make QMP APIs extensible
>>  * Clients (including libvirt) are used to QMP JSON RPC
>>
>> But maybe I should use QOM instead:
>>  * Add a "qom-find-objects-by-class" QMP command (Paolo's idea)
>>  * Client does "qom-find-objects-by-class IOThread /objects"
>>  * Client then uses "qom-get" to fetch the thread_id property on each
>>    IOThread object
>>  * But we haven't really established how QOM APIs will work
>
> 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 something like
> /objects/threads/thread0/pid.

/objects is the namespace for -object, but a similar idea is that 
objects could create links of themselves under other paths.  So you 
would have /threads where you can list iothread objects or /backend/rng 
for RNG backends.

Still Stefan doesn't like the idea of sending O(n) commands to query the 
thread ID of n iothread objects.

Paolo