From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZh62-0000ou-BD for qemu-devel@nongnu.org; Thu, 02 Oct 2014 10:11:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZh5t-0002lP-4o for qemu-devel@nongnu.org; Thu, 02 Oct 2014 10:11:06 -0400 Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:37194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZh5s-0002lH-U0 for qemu-devel@nongnu.org; Thu, 02 Oct 2014 10:10:57 -0400 Received: by mail-wi0-f179.google.com with SMTP id d1so4198024wiv.12 for ; Thu, 02 Oct 2014 07:10:56 -0700 (PDT) Date: Thu, 2 Oct 2014 15:10:53 +0100 From: Stefan Hajnoczi Message-ID: <20141002141053.GA6250@stefanha-thinkpad.redhat.com> References: <1412078370-3555-1-git-send-email-armbru@redhat.com> <87iok46kb8.fsf@blackfin.pond.sub.org> <20141002132119.GD30564@stefanha-thinkpad.redhat.com> <542D5284.1060201@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <542D5284.1060201@suse.de> Subject: Re: [Qemu-devel] IDs in QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: kwolf@redhat.com, peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, stefanha@redhat.com, Markus Armbruster , qemu-devel@nongnu.org, Anthony Liguori , Paolo Bonzini --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 02, 2014 at 03:26:28PM +0200, Andreas F=E4rber wrote: > Am 02.10.2014 um 15:21 schrieb Stefan Hajnoczi: > > On Wed, Oct 01, 2014 at 02:33:47PM +0200, Markus Armbruster wrote: > >> Markus Armbruster writes: > >=20 > > This discussion seems orthogonal to your patch. But I'm not applying it > > yet to give more time for discussion/review of the patch. > >=20 > >> Is mangling array-ness into the name really a good idea? Isn't this > >> type matter, not name matter? > >=20 > > I agree. It's nasty to hack the array selector into the name and will > > probably cause us pain down the line. > >=20 > >> Backtracking a bit... Unlike QMP object-add, -object ) and HMP > >> object-add use QemuOpts. See object_create(), commit 68d98d3 "vl: add > >> -object option to create QOM objects from the command line", and > >> hmp_object_add(), commit cff8b2c "monitor: add object-add (QMP) and > >> object_add (HMP) command". Parameter 'id' is the QemuOpts ID, thus > >> bound by its well-formedness rule. > >> > >> Therefore, -object and HMP object-add only support a subset of the > >> possible names. > >> > >> In particular, they do not permit "automatic arrayification". > >> > >> Should QOM names be (well-formed!) IDs? > >=20 > > Yes, I think that is sane. > >=20 > > Are there any invalid IDs used as QOM names today? > >=20 > > Hopefully the answer is no and we can lock everything down using > > id_wellformed(). >=20 > On IRC I was arguing against that, preferring some more specific > object_property_name_wellformed() or so. This could be called from > object_property_add(), with invalid names returning an Error *. >=20 > Only thing to check for would be '/'? Why risk the inability to specify QOM names via QemuOpts? What is the benefit of allowing two different sets of valid names? Stefan --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJULVztAAoJEJykq7OBq3PIx/kH/i7i19NBHpCwRmMWqBKScuHb l+tOA18ITRank9/HnIwQ4vq/0qMx3ERoXCELhmTYpY7hFZOQCZKd3tnvvHZ/YjUo vBVCCU8oS5yRRNsGWgpast50E7PyqnfmZ/qAXAzHjFHVU4ZZ4kKkBz1DvW4pHm5I DsyC9ShXoymqQhg+mCiiwXzWK8nQL5NuBigx7wixz3x6SaAaxww4z9O7k2L4d8hv rVq2cigSEbcS+xhIwamjTyNwh1PD0rN4u5Ug+QpkkikicAMxOg13Vca5y/pSi/Yo PvP9l4gsGULZ6YRjWyHpmZGieGqxUoGnZHKtOn1t9TY2MWtG0fvVcrc7JABf4R8= =F1bg -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk--