From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36409) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV2ip-0002dA-Kh for qemu-devel@nongnu.org; Thu, 27 Aug 2015 15:20:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZV2il-0001eg-0n for qemu-devel@nongnu.org; Thu, 27 Aug 2015 15:20:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV2ik-0001eG-PW for qemu-devel@nongnu.org; Thu, 27 Aug 2015 15:20:22 -0400 References: <29C62C49-06A5-4F99-8062-7269A28C29A3@gmail.com> <8737z7o85i.fsf@blackfin.pond.sub.org> <441C227A-2CF0-43AE-AC7F-B066708CEABD@gmail.com> <87fv36j9j6.fsf@blackfin.pond.sub.org> <20150826172550.GJ11016@localhost.localdomain> <20150826180815.GK11016@localhost.localdomain> <20150826220151.GA2669@localhost.localdomain> <2CB0CE30-A638-4933-A1D6-F65CA4910E61@gmail.com> <20150827123234.GB2669@localhost.localdomain> <55DF09DB.2000406@redhat.com> <55DF5E20.8080204@redhat.com> From: Eric Blake Message-ID: <55DF62F3.2060305@redhat.com> Date: Thu, 27 Aug 2015 13:20:19 -0600 MIME-Version: 1.0 In-Reply-To: <55DF5E20.8080204@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FH4dMSkMVHFrwoNU2AA0KaCJ5Whap0dWo" Subject: Re: [Qemu-devel] Should we auto-generate IDs? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , Jeff Cody , Programmingkid Cc: Kevin Wolf , Paolo Bonzini , Markus Armbruster , =?UTF-8?Q?Andreas_F=c3=a4rber?= , qemu-devel qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FH4dMSkMVHFrwoNU2AA0KaCJ5Whap0dWo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/27/2015 12:59 PM, John Snow wrote: >> Dan made the point that if a name is unpredictable, then we have >> to query to learn what name was assigned. But if you add two or >> more devices before querying, then you don't know which device has >> which name. Predictable might actually be better than >> non-predictable. >> >=20 > Can we add the information into the QMP response? Yes, any command that currently returns nothing (aka {}) can be expanded to return something useful, such as the name of the device just allocated, without breaking back-compat. That would be one less round trip (create a device, and the response is the devices name; rather than create a device and pass a second command to query its name). But remember that even things as trivial as creating a disk device may open several BDS and therefore create several named items at once, so we have to be careful that all the information can be parsed. On the bright side, Markus' introspection work would let us know if a command's return struct supplies the additional information. On the downside, management apps that want to talk to older qemu probably wouldn't use it anyways, as they have to have the fallback of supplying a name in the first place for older qemu, at which point supplying the name always is easier than making code conditional on whether qemu is new enough to introspect. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --FH4dMSkMVHFrwoNU2AA0KaCJ5Whap0dWo 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/ iQEcBAEBCAAGBQJV32L0AAoJEKeha0olJ0NqUUYH/2/lXBEgqHTRmBhRr8BQq7Op 8uPsYz+xPhazPxRiSxmkI6qswF/PV+sYQDoYH9cMb76ZIYP/zoiAR7yVjIvoFwxQ n2ZejXKtgDO8h6rvcmlGsMHQ64v9moBWaA4FWetxWbMfWOM3+YgjdZcuQuCpGJpb jmCJeq0CQsOBjgOek8KzXSzNkWt+7awMMIlSz0PUF8G3gJ/vwVDaeV3oXq92sIm3 uajuMfZRtNhKvicOrOQR2/zaIKKjkJbYNQFC1KnD+nCki9UVasvI6edKoQeyeJem pS9Azwu1E7WlgQI/rhOVHHRw6igQEOKs6vwybfadmp73FL0lis3tBoWWoL/QFwM= =wXa4 -----END PGP SIGNATURE----- --FH4dMSkMVHFrwoNU2AA0KaCJ5Whap0dWo--