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

[Anthony Liguori <aliguori@us.ibm.com>]

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:

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.

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.

Regards,

Anthony Liguori

  That path is resolved
> to an object reference before proceeding with the requested service. If
> an object should be serialized in whatever way and we need a stable
> name, a central service could return this by walking up the composition
> tree until a user-assigned name is found.
>
> So there is really no need to bother device model developers with the
> topics "How do I define a unique name?" or "Do I need an index or will
> there be never more than one foo device?".
>
> Jan
>