Re: [Qemu-devel] [PATCH 00/14] qdev: assign unique names to all devices (part 1)

[Jan Kiszka <jan.kiszka@siemens.com>]

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