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

[Anthony Liguori]

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.

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
>