[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QOM vs QAPI for QMP APIs
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] QOM vs QAPI for QMP APIs |
Date: |
Fri, 21 Feb 2014 06:29:35 -0800 |
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
>
- [Qemu-devel] QOM vs QAPI for QMP APIs, Stefan Hajnoczi, 2014/02/21
- Re: [Qemu-devel] QOM vs QAPI for QMP APIs,
Anthony Liguori <=
- Re: [Qemu-devel] QOM vs QAPI for QMP APIs, Paolo Bonzini, 2014/02/21
- Re: [Qemu-devel] QOM vs QAPI for QMP APIs, Eric Blake, 2014/02/21
- Re: [Qemu-devel] QOM vs QAPI for QMP APIs, Markus Armbruster, 2014/02/24
- Re: [Qemu-devel] QOM vs QAPI for QMP APIs, Eric Blake, 2014/02/24
- Re: [Qemu-devel] QOM vs QAPI for QMP APIs, Markus Armbruster, 2014/02/25
- Re: [Qemu-devel] QOM vs QAPI for QMP APIs, Andreas Färber, 2014/02/25
- Re: [Qemu-devel] QOM vs QAPI for QMP APIs, Paolo Bonzini, 2014/02/25
- Re: [Qemu-devel] QOM vs QAPI for QMP APIs, Andreas Färber, 2014/02/25
Re: [Qemu-devel] QOM vs QAPI for QMP APIs, Stefan Hajnoczi, 2014/02/21