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 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. It ends up being very similar to working with sysfs at that point. Regards, Anthony Liguori > So my question is: should we use QOM as the external API or continue > using QAPI? > > I don't think we gain much by switching to QOM other than opening a > whole new design space that we've yet to master. We'll make plenty of > mistakes just like we did with QMP and QAPI. > > Although QOM eliminates the need to implement dedicated QMP commands, it > exposes a more complex model to the client. Instead of a JSON > command/response model we now expose a general object-oriented namespace > with properties, links, etc. The client has to make sense of all that > and has to perform multiple qom-list/qom-get/etc commands for something > that would take a single dedicated QMP command. > > 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 :). > > Stefan >
