On 2011-09-16 20:03, Anthony Liguori wrote: > On 09/16/2011 12:11 PM, Kevin Wolf wrote: >> Am 16.09.2011 18:54, schrieb Anthony Liguori: >>> This series just asks the device model developer to come up with a unique >>> *when* >>> they're doing device composition. Even with a totally path based interface, >>> this is always going to be a firm requirement. >>> >>> I think it may be possible to eliminate required device names by having a >>> formal >>> notion of composition and have the devices store the names of the composed >>> devices as part of the reference to that device. You could then have user >>> created devices use a separate hash table to track the names of those >>> devices. >>> >>> But, we can't easily do this today. Having either a fully qualified name >>> or a >>> composition name as part of qdev_create() is the Right Thing IMHO so I think >>> this is the stepping stone to something more sophisticated. >> >> Actually, as I said, I think this naming scheme is already by far too >> sophisticated. Jan is completely right, there is no point in duplicating >> paths in a name. Either we assign names only if the user specified one, >> or we auto-generate a really simple name that doesn't resemble a path, >> can be easily typed and is actually useful to have in addition to paths >> (my "#foo-1" suggestion). > > Names have to be relatively stable. Instantiation ordering should not affect > names nor should hotplug. Otherwise two device models will end up with > devices > with different names. > > Jan's point is that there is a stable path that could be used for the name > and > satisfy these purposes. This is the composition path. Either a device is > created by the user (and therefore has a stable name and sits on the '/' part > of > the path) or is created through composition and has a derived named from a > user > created device. Since the composed device is tied to its parent's lifecycle, > the path is always valid. > > So this is a simplification that I plan on running with. For now, I think > this > series is the right next step because it gives us a path name for the name > (although different syntax) and let's us enforce that all devices has a > canonical path.
For something that changes lots of devices and, at the same time, is going to be removed again, I'm hesitating to call it the right direction. A right step would be, IMHO, to introduce a generic introspectable device link so that parent devices can reference their children and a visitor can derive a child's relative name from that link name. Then make sure this link type is consistently used. I really dislike this focusing on assigning names internally and using them in QEMU-internal APIs. They should just fall out of the core when external interaction is required. > > Independent of that, Jan suggested that we could have what's essentially an > alias. This is just a short name (could be in the form '%s-%d' % > (class.lower(), object_count). This alias is just a hash table. It has > nothing > to do with the core device model. I can't remember suggesting such thing. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
