Am 16.04.2014 08:42, schrieb Markus Armbruster: > Peter Crosthwaite <peter.crosthwa...@xilinx.com> writes: > >> On Wed, Apr 16, 2014 at 2:16 AM, Andreas Färber <afaer...@suse.de> wrote: >>> Am 15.04.2014 04:21, schrieb Peter Crosthwaite: >>>> So clients can set the top level id string. >>>> >>>> Signed-off-by: Peter Crosthwaite <peter.crosthwa...@xilinx.com> >>> >>> 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
