From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGxDh-0000YN-PS for qemu-devel@nongnu.org; Fri, 21 Feb 2014 16:01:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGxDX-0002hm-8t for qemu-devel@nongnu.org; Fri, 21 Feb 2014 16:01:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGxDX-0002hg-0B for qemu-devel@nongnu.org; Fri, 21 Feb 2014 16:01:07 -0500 Message-ID: <5307BE7A.5050007@redhat.com> Date: Fri, 21 Feb 2014 14:00:42 -0700 From: Eric Blake MIME-Version: 1.0 References: <20140221091629.GE11907@stefanha-thinkpad.redhat.com> <530764B0.40500@redhat.com> In-Reply-To: <530764B0.40500@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OsVdN8C0WA2EBBt54saFqgJ5dweB7UFuv" Subject: Re: [Qemu-devel] QOM vs QAPI for QMP APIs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Anthony Liguori , Stefan Hajnoczi Cc: qemu-devel@nongnu.org, Michael Roth , Andreas Faerber , Anthony Liguori , Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OsVdN8C0WA2EBBt54saFqgJ5dweB7UFuv Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. >=20 > /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. >=20 > Still Stefan doesn't like the idea of sending O(n) commands to query th= e > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --OsVdN8C0WA2EBBt54saFqgJ5dweB7UFuv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTB756AAoJEKeha0olJ0NqdGwH/i5qMLV0spQeYmrr5RLDfnPl DP1VvyWTHC2ee7BRGSVdU6C3FzDcHd8Tx+HN3hWIIHp9wJYF7iaNXHYS/myroPB1 S8rOeQYjjL5xCjvdk2BjFKK8IZXI6g1aMw2tHbkWjgACTRr9j47yUOZ28tYihbm4 h9HfJSOHbkDWzTN5WUkOCmBHz2YKdgmPh8R7248aftHdTWQw/HTjO8xZ/kc9g+wT ipbS2adfXPu0nXg+1PA3LMMomczZEi98yVwsX2RAx0VQiqC7vjiLJKdEKrGeFJ1z Zu9lajnK05fWhr0jXWs1brCze8Vfup8ofkGg/7YgSCU8jnWLJLVwJDntV3SQVH4= =W+rc -----END PGP SIGNATURE----- --OsVdN8C0WA2EBBt54saFqgJ5dweB7UFuv--