Andreas Färber <afaer...@suse.de> writes: > 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.
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!
