From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKTpM-0000Ks-9N for qemu-devel@nongnu.org; Wed, 29 Jul 2015 12:03:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKTpG-0005sD-D1 for qemu-devel@nongnu.org; Wed, 29 Jul 2015 12:03:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKTpG-0005rj-4g for qemu-devel@nongnu.org; Wed, 29 Jul 2015 12:03:26 -0400 References: <1435782155-31412-1-git-send-email-armbru@redhat.com> <1435782155-31412-48-git-send-email-armbru@redhat.com> <55B1B490.6000402@redhat.com> <87wpxkp2bp.fsf@blackfin.pond.sub.org> <55B7F4DE.3040807@redhat.com> <87zj2fgvcz.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <55B8F94A.2060902@redhat.com> Date: Wed, 29 Jul 2015 10:03:22 -0600 MIME-Version: 1.0 In-Reply-To: <87zj2fgvcz.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="40jKndUr7E0mv7OJba8LTlwcmp94UbFBS" Subject: Re: [Qemu-devel] [PATCH RFC v2 47/47] qapi-introspect: Hide type names List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --40jKndUr7E0mv7OJba8LTlwcmp94UbFBS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/29/2015 03:34 AM, Markus Armbruster wrote: >>>> I'm not sure whether I like this or not. It does make sense from th= e >>>> perspective of forcing clients to stick to ABI queries, but makes it= a >>>> bit harder to navigate things except by automated scripts. >>> >>> Yes. I'm not sure it's a good idea. If we decide to hide types this= >>> way, then I'd find an option to generate without type hiding useful. >> >> As in, an optional boolean flag to the QMP command that requests wheth= er >> to get compact output with hidden names vs. full output with qapi name= s >> exposed (but then, are we storing TWO copies of the introspection >> strings)? Or merely as in the generated qmp-introspect.c file having >> strategic comments so that reading _that_ file lets you see the type >> names, even if they don't get passed on to the end user? >=20 > I was thinking of optionally unhidden type names, for when you messed u= p > the output, and the stupid hidden type names make it hard to see what > exactly's wrong. I.e. the option is merely a development aid. Ah, an option to qapi-introspect.py that says to generate the file differently, but which is not normally enabled and therefore not exposed to the QMP end user. That, or unconditional strategic comments, both do the trick for me. >=20 >>> What the patch adds: >>> >>> Move the introspection information for the non-types out of the way >>> before the loop, append the information on types afterwards. The res= ult >>> is now in jsons rather than self.jsons (see the next patch hunk). >> >> I did notice that; pre-patch interleaved commands and types all >> according to a global namespace, while post-patch sank all types to th= e >> bottom. Interestingly enough, if libvirt is going to query what >> features a command has, it will first find the command (in the first >> half of the returned array), then resolve the types used by that comma= nd >> until it learns if the member is present (whether new enum value or >> added dictionary member) - so there is that slight optimization that i= f >> we guarantee that types are always output last, then libvirt doesn't >> have to start generating its own hash table lookup of types until the >> first type is seen, after already learning everything it needed from t= he >> earlier command listings. >=20 > I'm reluctant to complicate the contract with such a promise, though. Concur. If we aren't going to guarantee sorting, then we also should not guarantee that all commands come before any types, but that the overall output is just an entire lookup dictionary where any entry can hold any metatype. >=20 > I guess I'd simply slurp in the JSON, then do a quick pass over the > resulting data structure to build an index. Yep, that's probably what I'll have to code into libvirt. >=20 > That's the easy order. Other orders are possible, but they're extra > work. Best to keep things simple. Simplest for qemu is no order at all (and the client has to take on the burden of sorting things as desired). Not always the smartest (if every client wants to sort, we've pushed a lot of duplicated work onto each client instead of doing the work ourselves), but we have right up until 2.5 is released to commit to our decision of whether to sort in qemu or n= ot. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --40jKndUr7E0mv7OJba8LTlwcmp94UbFBS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVuPlKAAoJEKeha0olJ0NqSMcIAKHQNbJEznG0eaA/8kXJud/Y JnkncI01w+8ruOu//ZKhsep5vltQt8/D7KxVBpO9wV0ZihrwmktTUCT8QLf/hAKG 6GeJfLnwXfUcA5g5B37CFCF2lman0WtSBNUBUq17cxKcVOAMKuoISayAk8LmKTgf Y9kKngwXfUiydOiJVCicJuy1dnX2Dk1jGbculQQXWGNRVqJ/pFL1SZZL4AgVXMRq PlR+BoEyI6EyhN5cm38Kgq23j5WT4rPVuzqguzoSncTceyJxeGcLGtiQI0cKL0lJ mmo0wrIXDbABPSnyirozcrCtKGc+rvLTgoej3xVMXTC3UASSpZ25Cj+vEqNwJiE= =GIL9 -----END PGP SIGNATURE----- --40jKndUr7E0mv7OJba8LTlwcmp94UbFBS--