Re: [Qemu-devel] [PATCH qemu] qom: Document qom/device-list-properties implementation specific

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> On 02/05/2018 11:38, Markus Armbruster wrote:
>>>>> It probably is not unless someone adds properties in realize() callback,
>>>> Now work that into the doc comment, please :)
>>> Are there any examples?
>> There must be examples where instances of the same type have different
>> properties, or else our design decision to create properties dynamically
>> was inane.
>
> Buses for example create properties at runtime to link a parent to its
> children.  These properties are created when a child device appears;
> this is different from creating properties in or the realize() callback,
> or upon setting other properties.
>
> The purpose of this command is to tell people/tools what they can pass
> to -device/-object/device_add/object_add, so the real question is
> whether there are cases where it falls short of that purpose.
>
> If not,

Do we have to be certain?  Or would "we don't think so" be enough?

>         maybe the wording for the .json file could be something like:
>
>   Objects can create properties at runtime, for example to describe
>   links between different devices and/or objects.  These properties
>   are not included in the output of this command.

Not bad.

In theory, objects can also create properties in response to non-default
configuration, and these would also not be included.  Objects could even
create a property with the same name, but different type or description.
Arguably capital-letter Bad Ideas, but nothing prevents such misuse.

Since I'm in a generous mood, I'd rate the thing at Rusty API level 4
"Follow common convention and you'll get it right."

https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html

If dynamic properties are really just for internal use, as you seem to
suggest in Message-ID:
<address@hidden>, then we should've had
the common sense to unambiguously separate them from the user-facing
properties.  Can we still do that?