Re: [Qemu-devel] [PATCH 4/5] monitor: add object-add (QMP) and object_add (HMP) command

[Luiz Capitulino <lcapitulino@redhat.com>]

On Tue, 10 Dec 2013 19:15:05 +0100
Paolo Bonzini <pbonzini@redhat.com> 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.