From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWnuC-0004re-8Z for qemu-devel@nongnu.org; Tue, 01 Sep 2015 11:55:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWnu6-00010x-Df for qemu-devel@nongnu.org; Tue, 01 Sep 2015 11:55:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWnu6-0000zg-7N for qemu-devel@nongnu.org; Tue, 01 Sep 2015 11:55:22 -0400 References: <1441101059-14269-1-git-send-email-berrange@redhat.com> <55E5A569.3030603@suse.de> <20150901132327.GD6860@redhat.com> From: Eric Blake Message-ID: <55E5CA66.3070200@redhat.com> Date: Tue, 1 Sep 2015 09:55:18 -0600 MIME-Version: 1.0 In-Reply-To: <20150901132327.GD6860@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ljnvLougocv4WuFcW4kmarSPP1KO7PExn" Subject: Re: [Qemu-devel] [PATCH v3] monitor: allow object_del & device_del to accept QOM paths List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , =?UTF-8?Q?Andreas_F=c3=a4rber?= Cc: Programmingkid , Gonglei , qemu-devel@nongnu.org, Paolo Bonzini , Markus Armbruster This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ljnvLougocv4WuFcW4kmarSPP1KO7PExn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/01/2015 07:23 AM, Daniel P. Berrange wrote: >>> +Remove device @var{id}. @var{id} may be a short ID >>> +or a QOM object path. >> >> Have you considered using two alternative parameters, id and qom-path?= >> (qom_path was used elsewhere) >=20 > I'm not fussed either way, but I thought it simpler to not try to chang= e > the accepted parameters of the existing commands. Looking, the only > place I notice that uses a 'qom_path' is the return data in the CpuInfo= > struct. >=20 > Does anyone have strong feelings either way about use of id for both vs= > qom-path or id ? Reusing 'id': - Pros - less complicated interface (don't have to check for mutual exclusion)= - Cons - not introspectible (can't tell by introspection alone whether id can take a QOM path) - confusing name (but not the first time we've had that issue) Adding 'qom-path': - Pros - introspectible - JSON expresses everything (we don't have to parse the first character of the string to know which style was meant, as the choice of key already decided it) - Cons - Have to implement mutual exclusion ourselves (can't take 'id' and 'qom-path' at the same time, and at least one must be specified), unless we invent a new way for qapi to express mutual exclusion (there are other existing commands that would benefit from such an extension) How likely is libvirt to need to introspect whether this extension is available? We've already argued that libvirt should already be giving everything an id, and therefore, the existing semantics of 'id' are already sufficient for libvirt's needs, and libvirt will never need to delete by qom-path, and thus does not need to introspect whether qom-path even works. Therefore, I'm leaning towards simplicity rather than introspection; and the patch is fine as-is from my viewpoint. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ljnvLougocv4WuFcW4kmarSPP1KO7PExn 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/ iQEcBAEBCAAGBQJV5cpmAAoJEKeha0olJ0NqJCgH/RCN2FT6NEYg+6zpvhNlz9vY V9qCDPCFfKIlYWOteTLQhC240slY9rv/CY2SvAds6nGTLjyThVyYk1DL7uh/kKRb NHP5FhyGzMKE4PjCAqrIxHA3WeU0+HXM1znYh35dXVp1bWZCRwiYUd1OKwFm4Oom FDlj+7xwOaIH2WPq/FGMO9XEJ2WjgN59kbmArr081FHiSoWhR5DFuoBjbn4snoNK 1KQgvxjD/VYzug+fFnctcWMuKzoA/4s6ONaXU0fhm2zlWEjnFLs1rRNUvXxKPlf8 eBJJPWyJlmrJ9/molV+UBFxDonc1sUOkcT1+1UtFgdxky/cs4Eteju5zq8r/Qks= =ep8J -----END PGP SIGNATURE----- --ljnvLougocv4WuFcW4kmarSPP1KO7PExn--