Re: [Qemu-devel] 答复： Re: [PATCH v2] object: Add 'help' option for all available backends and properties

[Markus Armbruster]

Andreas Färber <address@hidden> writes:

> Hi Lin and Markus,
>
> Am 19.09.2016 um 13:58 schrieb Markus Armbruster:
[...]
>> You're messing with struct EnumProperty because you want more help than
>> what ObjectPropertyInfo can provice.
>> 
>> Digression on the meaning of ObjectPropertyInfo.  This is its
>> definition:
>> 
>> ##
>> # @ObjectPropertyInfo:
>> #
>> # @name: the name of the property
>> #
>> # @type: the type of the property.  This will typically come in one of four
>> #        forms:
>> #
>> #        1) A primitive type such as 'u8', 'u16', 'bool', 'str', or 'double'.
>> #           These types are mapped to the appropriate JSON type.
>> #
>> #        2) A child type in the form 'child<subtype>' where subtype is a qdev
>> #           device type name.  Child properties create the composition tree.
>> #
>> #        3) A link type in the form 'link<subtype>' where subtype is a qdev
>> #           device type name.  Link properties form the device model graph.
>> #
>> # Since: 1.2
>> ##
>> { 'struct': 'ObjectPropertyInfo',
>>   'data': { 'name': 'str', 'type': 'str' } }
>> 
>> @type is documented to be either a primitive type, a child type or a
>> link.  "Primitive type" isn't defined.  The examples given suggest it's
>> a QAPI built-in type.  If that's correct, clause 1) does not cover
>> enumeration types.  However, it doesn't seem to be correct: I observ
>> 'string', not 'str'.  Paolo, Andreas, any idea what @type is supposed to
>> mean?
>> 
>> End of digression.
>> 
>> All ObjectPropertyInfo gives you is two strings: a name and a type.  If
>> you need more information than that, you have to add a proper interface
>> to get it!  Say a function that takes an object and a property name, and
>> returns information about the property's type.  Probably should be two
>> functions, one that maps QOM object and property name to the property's
>> QOM type, one that maps a QOM type to QOM type information.
>> 
>> In other words, you need QOM object and type introspection.  Paolo,
>> Andreas, if that already exists in some form, please point us to it.
>
> Could you say what exactly you want to introspect here?

Context: Lin wants to implement "-object TYPE-NAME,help", similar to
"-device DRIVER-NAME,help", i.e. list the available properties of
TYPE-NAME.

His proposed patch tries to give better help for enumeration types by
listing the acceptable values.  The code that does it is an unacceptable
hack, though.  We're trying to figure out a way to provide such help
cleanly.

One way to do it would be introspecting QOM *types*.  Find the
property's type, figure out what kind of type it is, if it's an
enumeration type, find its members, ...

> Both ObjectClass and Object have a list of properties that together form
> the list of properties that can be set on an instance. So you'll need to
> instantiate the object like I think we do for devices. Then you can
> recursively enumerate the properties to get their names and types (and
> possibly put them into a new list for alphabetical sorting if desired).

Lin's code uses object_new() to instantiate a dummy object,
object_property_iter_init() and object_property_iter_next() to find the
properties.  Sounds okay so far, doesn't it?

Hmm, ObjectProperty has members name, type, description.  Could
description be useful?  I guess it's set with
object_property_set_description().  I can see only a few dozen calls,
which makes me suspect it's null more often than not.

When it's null we could still fall back to a description of the type.
Does such a thing exist?  Enumeration types could provide one listing
their values.

Other ideas?