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

[Paolo Bonzini]

On 02/05/2018 14:36, Markus Armbruster wrote:
>> 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?

I think it's 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.

Thanks. :)

> 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

I wouldn't say they are for internal use.  They are somewhat orthogonal
to the _intended_ use case of this command though.   Somebody is bound
to be annoyed by them anyway, but that's sort of expected with dynamic
stuff.

> , 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?

We do have infrastructure for class properties, we just don't use it much.

Paolo