From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VseNe-0006ts-B6 for qemu-devel@nongnu.org; Mon, 16 Dec 2013 15:03:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VseNV-0005ux-Ap for qemu-devel@nongnu.org; Mon, 16 Dec 2013 15:03:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VseNV-0005uq-2u for qemu-devel@nongnu.org; Mon, 16 Dec 2013 15:02:57 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBGK2uOg010612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Dec 2013 15:02:56 -0500 Date: Mon, 16 Dec 2013 15:02:54 -0500 From: Luiz Capitulino Message-ID: <20131216150254.75ef86f6@redhat.com> In-Reply-To: <52A75A29.1030204@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Paolo Bonzini Cc: imammedo@redhat.com, akong@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com 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.