On 29/05/20 08:57, Markus Armbruster wrote:
> QMP qom-get for a link property returns the canonical path of the link's
> target:
>
> $ socat "READLINE,history=$HOME/.qmp_history,prompt=QMP> "
> UNIX-CONNECT:$HOME/work/images/test-qmp
> [...]
> QMP> {"execute": "qom-get", "arguments": {"path": "/machine", "property":
> "acpi-device"}}
> {"return": "/machine/unattached/device[23]"}
>
> This makes sense.
>
> Fine print: it returns "" for dangling links, I think. See
> object_get_link_property().
>
> qom-get behaves the same for child properties:
>
> QMP> {"execute": "qom-get", "arguments": {"path": "/machine", "property":
> "peripheral"}}
> {"return": "/machine/peripheral"}
>
> This surprised me. I'm writing to the list in the hope of saving
> somebody else the surprise and the time to figure out what's going on
> here.
>
> Returning the canonical path feels useless here. The only explanation
> that comes to my mind is we have to return something, the canonical path
> is something, therefore we have to return it ;)
It is useful in that the caller need not care whether a property is a
child or a link. If a property has object type, it consistently returns
a canonical path.
> You either just know that /machine/peripheral is a child property, or
> you recognize the pattern "type": "child<T>" in output of qom-list one
> level up:
>
> QMP>{"execute":"qom-list","arguments":{"path":"/machine"}}
> {"return": [... {"name": "peripheral", "type": "child<container>"}, ...]}
>
> I believe ad hoc matching of type strings is necessary in other cases to
> make sense of qom-get output.
>
> I wish QOM introspection described types like QAPI introspection does.
At least in theory all QOM property types should be one of child<>,
link<> or a QAPI type. Perhaps it should have been just the QOM type
without the child<> and link<> annotations? Can we change that
retroactively? (We probably can).
Paolo
