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.
How can we change it? The problem I am trying to solve, is getting meaningful device instance names instead of the anonymous defaults. This includes in the canonical path. I am completely open to proposals :) Using a dynamic property might allow us to > unparent while keeping a reference and then add it as a child<> again, > but that still feels awkward. Eww. Having it as a getter only seem more > secure and predictable. > Sure, once it's committed to the canonical path it definitely needs a read-only semantic. Shouldn't be hugely different to the writable-until-realize semantic of qdev props though? > Another issue is bus naming. If supplied NULL, the bus will be based on > ID. If the ID changes, bus naming will be inconsistent. > Or rather - what the user intends. If the board has 2 USB busses named "foo" and "bar", then those should be both the canonical path and bus names. Rather than the homogenised default names "usb0", "usb1". > Why would clients set the ID after having chosen a different ID I'm lost here - what is the mechanism by which you can validly set per-instance IDs? Regards, Peter or > anonymity? > > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg >
