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 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
