qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v1 1/3] qdev: Expose the qdev id string as a prop
Date: Wed, 16 Apr 2014 17:16:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

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.

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.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]