[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QOM vs QAPI for QMP APIs
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] QOM vs QAPI for QMP APIs |
Date: |
Fri, 21 Feb 2014 14:00:42 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
On 02/21/2014 07:37 AM, Paolo Bonzini wrote:
>> 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.
The other burden is documenting what QOM paths to be queried, and
knowing where to find that documentation. That is, it's another layer
of complexity, but it's also a more powerful expression.
I'm comparing this situation somewhat to libvirt's 'virsh
qemu-monitor-command' vs. other libvirt commands. qemu-monitor-command
is a more powerful interface (via libvirt, you can issue ANY qmp
command), and is therefore great for development for testing something
that libvirt has not yet supported; but not so nice to the end user
(it's use is explicitly unsupported). What happens is that as people
say "I had to use qemu-monitor-command to do task A", it is a hint to
libvirt development to say "oh, we need to add an API to make task A
easier to do".
Thus, having qom-find-objects-by-class is a good idea, even if it is
more awkward to use than a dedicated qmp command. But meanwhile, we
should watch what common patterns it gets used for, and add dedicated
QMP commands for those patterns. It's much faster to get a chunk of
information in one QMP call already formatted into desired structs than
it is to make a series of QMP calls to learn about the lower-level qom
model one piece at a time.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] QOM vs QAPI for QMP APIs, Stefan Hajnoczi, 2014/02/21
- Re: [Qemu-devel] QOM vs QAPI for QMP APIs, Anthony Liguori, 2014/02/21
- 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 <=
- 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