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

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> 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.

That makes me suspect that...

>                                                      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.

... the sane thing to do would be to limit this command to class
properties, and use class properties for anything that doesn't *have* to
be dynamic.  The second half of the sane thing looks like a substantial
chunk of work, though.