qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] QOM vs QAPI for QMP APIs
Date: Fri, 21 Feb 2014 15:37:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Il 21/02/2014 15:29, Anthony Liguori ha scritto:
On Fri, Feb 21, 2014 at 1:16 AM, Stefan Hajnoczi <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]