Re: [Qemu-devel] [PATCH v1 1/3] qdev: Expose the qdev id string as a prop

[Markus Armbruster]

Andreas Färber <address@hidden> writes:

> Am 16.04.2014 08:42, schrieb Markus Armbruster:
>> Peter Crosthwaite <address@hidden> writes:
>> 
>>> On Wed, Apr 16, 2014 at 2:16 AM, Andreas Färber <address@hidden> wrote:
>>>> Am 15.04.2014 04:21, schrieb Peter Crosthwaite:
>>>>> So clients can set the top level id string.
>>>>>
>>>>> Signed-off-by: Peter Crosthwaite <address@hidden>
>>>>
>>>> Anthony had nack'ed Paolo's attempt to generalize the qdev id to QOM, so
>>>> I'm not sure if we should really do this even if just on device level.
>>>> The id= is used to construct the canonical path, and we can't change
>>>> that through a qdev setter.
>> 
>> Let me try to paraphrase to make sure I got you: The canonical QOM path
>> is fixed at creation time.  Setting an ID dynamically would destroy the
>> relationship between ID and canonical QOM path.  Correct?
>
> Kind of.
>
> If we use, say, qemu-system-x86_64 -device nec-usb-xhci, then it ends up
> as /machine/peripheral-anon/device[0] currently. No problem.
>
> If we instead use qemu-system-x86_64 -device nec-usb-xhci,id=foo, then
> it becomes /machine/peripheral/foo, with "foo" being the name of the
> child<> property named after the id= value.
> Not only can there be just one canonical path, each object can only have
> just one parent. So either /machine/peripheral/foo remains when renamed
> to ID bar, or we need to destroy .../foo and then re-create .../bar. I'm
> not aware of any precedent for the latter, so it would require some care
> to not let the object die for lack of references in the middle of the
> operation, for instance, or to survive unparenting at all due to bad
> programmer assumptions.

Moving a live device around doesn't strike me as a good idea.

> While at QMP level link<> properties are treated as string paths, at QOM
> level they are represented as C pointers and the canonical path is
> reconstructed in the property getter. I.e., link<>s would not break if
> the canonical path changes, but a QMP user may get confused.

Indeed.

Thanks!