From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56952) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adKyV-0008Dm-He for qemu-devel@nongnu.org; Tue, 08 Mar 2016 11:59:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adKyS-0002az-A4 for qemu-devel@nongnu.org; Tue, 08 Mar 2016 11:59:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adKyS-0002as-27 for qemu-devel@nongnu.org; Tue, 08 Mar 2016 11:59:08 -0500 References: <1457194595-16189-1-git-send-email-eblake@redhat.com> <1457194595-16189-11-git-send-email-eblake@redhat.com> <87lh5s6hpz.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <56DF04D9.4040403@redhat.com> Date: Tue, 8 Mar 2016 09:59:05 -0700 MIME-Version: 1.0 In-Reply-To: <87lh5s6hpz.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aLpX7gCFpE1O4iBkaDLjsNXoh7EH2itVK" Subject: Re: [Qemu-devel] [PATCH v4 10/10] qapi: Populate info['name'] for each entity List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Michael Roth This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aLpX7gCFpE1O4iBkaDLjsNXoh7EH2itVK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/08/2016 09:46 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> Every non-implicit entity is associated with an 'info' >> dictionary, but it is not easy to reverse-engineer the name of >> the top-most entity associated with that 'info'. Our use of >> 'case_whitelist' (added in commit 893e1f2) is thus currently >> tied to the owner of a member instead; but as the previous patch >> showed with CpuInfo, this requires whitelist exceptions to know >> how an implicit name will be generated. >=20 > Why is that a problem? Not necessarily a bad problem, but a bit annoying. If a developer modifies a .json file and adds an improper name, then they will get an error message that tells them that they need to fix their naming conventions (hmm, the error message doesn't even point them to the whitelist - see args-member-case.err). If the developer figures out that the whitelist will let them avoid the error, they still have to figure _what_ name to add to the whitelist, and without this patch, they have to determine the generated name for the implicit struct (which may not be constant, since we are discussing about alternative names earlier in the series other than something that flattens to a public 'struct _obj_...' in violation of file-local naming scope). The goal is thus to make the whitelist tied only to names mentioned in the .json file, rather than dragging generated implicit names into the mix. But it is cosmetic; we could live without the patch and stick to generated names in the whitelist, just as easily. >=20 >> While we have a ._pretty_owner() that maps from implicit names >> back to a human readable phrase, that produces more than just a >> plain top-level entity name. What's more, the current use of >> ._pretty_owner() is via .check_clash(), which can be called on >> the same member object more than once (once through the >> standalone type, and a second time when used as a base class of >> a derived tpye); if a clash is only introduced in the derived >> class, using ._pretty_owner() to report the error on behalf of >> the base class named in member.owner seems wrong. Therefore, >> we need a new mechanism. >=20 > Now I'm confused. Are you fixing suboptimal error messages? No, I was trying to document why ._pretty_owner() (which is our only pre-exisiting map from Python objects back to pretty type names) is insufficient for the task at hand (namely, what is the pretty name of the type to add to the whitelist, if we don't want generated implicit names in the whitelist). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --aLpX7gCFpE1O4iBkaDLjsNXoh7EH2itVK 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/ iQEcBAEBCAAGBQJW3wTaAAoJEKeha0olJ0NqfMkH/jy2E3sfXUsXjhsYtNur0uu1 GGMIoPIgKQkxNxoty3Xfc7URcr542v6vIz2sOZwFOTvLl/3qWQg0FjasU3Mqvvcq CSGCgaLX/OQX1saVMM/4V3g88ulQzcCsOVw30tMAHVKwwhv+mM2HFUeosTejFPt1 6dM5yRwVBtyPDst83n+NiOmQ1A1oxgXUuc60mLiFhKUv9eJz+juuH87B2ccPvg7P 3fktkTbgcZdf646IW3xnuQ7t7paoNwSRMX+3Y32YUvEHSFfQ5tN4U6u3aktZWMXz rOw7eyj7uglG7223hz5LRu18Tkwtve2Jlsejgmnb8AdqGi9C3N+QYnlGrBieIaA= =6yEG -----END PGP SIGNATURE----- --aLpX7gCFpE1O4iBkaDLjsNXoh7EH2itVK--