From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtlXQ-0004ec-G4 for qemu-devel@nongnu.org; Thu, 19 Dec 2013 16:53:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtlXH-00025o-HG for qemu-devel@nongnu.org; Thu, 19 Dec 2013 16:53:48 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:38458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtlXH-00025f-DC for qemu-devel@nongnu.org; Thu, 19 Dec 2013 16:53:39 -0500 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 19 Dec 2013 16:53:38 -0500 Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 4946DC9003E for ; Thu, 19 Dec 2013 16:53:33 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp22034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rBJLrZUd3539340 for ; Thu, 19 Dec 2013 21:53:35 GMT Received: from d01av02.pok.ibm.com (localhost [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rBJLrYGn006939 for ; Thu, 19 Dec 2013 16:53:34 -0500 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth In-Reply-To: <87haa83pvz.fsf@blackfin.pond.sub.org> References: <1386694828-19786-1-git-send-email-pbonzini@redhat.com> <1386694828-19786-5-git-send-email-pbonzini@redhat.com> <52A756AF.7000309@redhat.com> <52A75A29.1030204@redhat.com> <20131216150254.75ef86f6@redhat.com> <87haa83pvz.fsf@blackfin.pond.sub.org> Message-ID: <20131219215332.11040.45527@loki> Date: Thu, 19 Dec 2013 15:53:32 -0600 Subject: Re: [Qemu-devel] [PATCH 4/5] monitor: add object-add (QMP) and object_add (HMP) command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Luiz Capitulino Cc: qemu-devel@nongnu.org, Anthony Liguori , imammedo@redhat.com, Paolo Bonzini , akong@redhat.com Quoting Markus Armbruster (2013-12-17 01:20:16) > [Cc: Anthony, Mike for QAPI schema expertise] > = > Luiz Capitulino writes: > = > > On Tue, 10 Dec 2013 19:15:05 +0100 > > Paolo Bonzini wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> = > >> Il 10/12/2013 19:00, Eric Blake ha scritto: > >> >>> + 'data': {'qom-type': 'str', 'id': 'str', '*props': 'dict'}, = > >> >>> + 'gen': 'no' } > >> > = > >> > This feels VERY open-coded. No where else in qapi-schema do we = > >> > have 'dict' as a type > >> = > >> Yes, in fact the "data" field is entirely skipped by the code > >> generator (that's 'gen':'no'). > >> = > >> > ; using it violates all sorts of type-safety (which, I guess, is = > >> > the point), making it impossible to introspect what keys are valid > >> > for use in the "props":{...} dictionary. Do we really want to = > >> > play this fast and loose with the type system, or should we try = > >> > harder to make this a robust self-describing union of types? > >> > = > >> > That is, why can't we have object-add use a discriminated union, = > >> > where qom-type is the discriminator, and where props is an = > >> > appropriate JSON struct type that corresponds to the branch of the > >> > union, so that we get full introspection on the set of valid keys > >> > to put in props for any given qom-type? > >> = > >> The point of "props" is passing arbitrary data to a QOM object. We > >> should indeed have introspection for QOM objects, where each QOM class > >> name can be introspected separately. However, the union of all > >> possible QOM objects need not have a "C struct" representation. > > > > The "props" key was added to represent the "O" argument type of > > early QMP (which is used by commands like device_add), so that > > we could convert them to the QAPI. IIRC, we didn't plan for it > > to be used by new commands... But I don't have anything better > > to suggest, so I won't object to its usage here. > = > We created monitor argument type "O" to have name=3Dval,... arguments in > the human monitor exactly like command line option arguments. Currently > used by device_add and netdev_add. > = > We shoehorned type "O" into QMP in a bout of QMP feature-completeness > desperation. This was before QAPI. > = > device_add still isn't in qapi-schema.json, but netdev_add is: > = > { 'command': 'netdev_add', > 'data': {'type': 'str', 'id': 'str', '*props': '**'}, > 'gen': 'no' } > = > Note the magic "'*props': '**'" (I'll be hanged if I know what that > means[*]), and "'gen': 'no'". > = > Yes, a proper schema for netdev_add and device_add is desirable. In > both cases (but especially for device_add), the arguments are the > obligatory id plus a union discriminated by the device type, contraining > that device's properties. > = > Unless we move device properties definition to qapi-schema.json (bad), > or duplicate them there (worse), we need to derive that part of the > schema dynamically from device information available in QOM. Is dumping static properties based on class name sufficient, or do we need introspection for dynamic properties as well? (or are those not exposed outside of qom-set?) We could maybe introduce a QAPI 'built-in' such as 'ObjectProperties' that automatically does the query based on the now-special 'type' param and handles all the type-checking up-front. This would avoid an open-ended 'dict' type proliferating too much and provide infrastructure for introspection. > = > = > [*] Can we have a definition of QAPI schema semantics other than code? > Pretty-please?