From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHy5N-0002VN-IF for qemu-devel@nongnu.org; Mon, 24 Feb 2014 11:08:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHy5G-0007vj-R6 for qemu-devel@nongnu.org; Mon, 24 Feb 2014 11:08:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37363) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHy5G-0007vP-IC for qemu-devel@nongnu.org; Mon, 24 Feb 2014 11:08:46 -0500 Message-ID: <530B6E85.30709@redhat.com> Date: Mon, 24 Feb 2014 09:08:37 -0700 From: Eric Blake MIME-Version: 1.0 References: <20140221091629.GE11907@stefanha-thinkpad.redhat.com> <530764B0.40500@redhat.com> <5307BE7A.5050007@redhat.com> <87ha7o6hhj.fsf@blackfin.pond.sub.org> In-Reply-To: <87ha7o6hhj.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9KxdibuGFebDpLMUumLormvi3KrBC8qNg" Subject: Re: [Qemu-devel] QOM vs QAPI for QMP APIs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Anthony Liguori , Michael Roth , qemu-devel@nongnu.org, Stefan Hajnoczi , Paolo Bonzini , Luiz Capitulino , Andreas Faerber , Anthony Liguori This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9KxdibuGFebDpLMUumLormvi3KrBC8qNg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/24/2014 01:29 AM, Markus Armbruster wrote: >> >> 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-comman= d >> 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 tha= n >> it is to make a series of QMP calls to learn about the lower-level qom= >> model one piece at a time. >=20 > You didn't spell out the ABI promises here. Do you argue for providing= > QOM interfaces as unstable low-level interfaces? Haven't we already done that in the past? For example, object-add currently takes an unspecified dictionary of options, where you would have to consult QOM documentation to learn what makes sense to send. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --9KxdibuGFebDpLMUumLormvi3KrBC8qNg 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/ iQEcBAEBCAAGBQJTC26FAAoJEKeha0olJ0NqgQ4H/i6ci9RhZhvrcyfOgBJCgEpG 09h8rtxC8rbAokW2n1IKLI/jDt3gK5t5nwAo906WOswi6cUCPukUQOyclHZO3Reb CaH37JQn6fV7mAdAQZEYyW5gXPgXl27kg9mhzN1DuXBgktruhB2ESbVptO9hIZ/X 8dhVSOsYNwPr8XjJB3vKc+iPMU7oeuKyH+ZkYgWddlj1pfC0rd9Z+Ar6dPOSX2HC coWqZK8sC/kMs3Wvp6rvYEGizDsK9eYdxkpLuqjirmBR1IR10srS1C9VNjyprtTf lWd3Aatj7+UYQOkWbUbVMqhpJ3A+cukujX7p4vhwoJ/TZq2dgTg6FjKBH7sDsw4= =/GE8 -----END PGP SIGNATURE----- --9KxdibuGFebDpLMUumLormvi3KrBC8qNg--