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:21, Anthony Liguori wrote:
> On 09/16/2011 11:48 AM, Jan Kiszka wrote:
>> On 2011-09-16 18:00, Anthony Liguori wrote:
>>> This series introduces an infrastructure to remove anonymous devices from qdev.
>>> Anonymous devices are one of the big gaps between qdev and QOM so removing is
>>> a prerequisite to incrementally merging QOM.
>>>
>>> Besides the infrastructure, I also converted almost all of the possible PC
>>> devices to have unique names.  Please not that naming is not a property of
>>> devices but rather of the thing that creates the devices (usually machines).
>>>
>>> The names are ugly but this is because of the alternating device/bus hierarchy
>>> in qdev.  For now, the names use '::' as deliminators but I think Jan has
>>> convinced me that down the road, we should use '/' as a deliminator such that
>>> the resulting names are actually valid paths (using a canonical path format).
>>
>> I still don't see why we need to store strings as device references.
>> Everyone that lacks a reference (QEMU-external users) can pass in a path
>> - which can be a device name in the simple case.
> 
> Thinking more about this.  I think a critical requirement is to be able to ask a 
> device how to reference itself.  IOW, there needs to be a device_get_name(dev) 
> that returns something that can be meaningfully used to later reference the device.
> 
> With your no name stored in a device proposal, you would have something like this:

I would not even store a name in the device unless it is user-assigned.
That can be created on demand if we did our homework correctly.

> 
> const char *device_get_name(Device *dev)
> {
>     if (dev->parent) { // created through composition, ask parent
>         return device_get_child_name(dev->parent, dev);
>     } else { // user created, return user supplied name
>         return dev->name;
>     }
> }
> 
> device_get_child_name() ends up becoming complicated unless you maintain a list 
> of children and their name mappings.  That means Device needs to store a hash 
> table even though those pointers are not the canonical references since the 
> composition devices are embedded in the parent Device.

As said in the other mail, the link name of the parent to its child is
the name we need to look up here. In turn that means a child likely
should know what link is referring to it in the composing parent. Can be
a feature of a generic device link so that we can also easily walk
graphs in both directions.

> 
> I think this leads to a lot of complexity without much real life gain.  I think 
> having the parent generate and set the child's name during creation is a 
> significant simplification.

The parent creates the name, no question, but in a different way you
still think of: by naming its link. Let's focus on how to do
inter-device referencing. This is actually the more important topic IMO,
but if we do it right, naming just falls out of it as a byproduct.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux