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

[Anthony Liguori]

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