[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 00/14] qdev: assign unique names to all devices (part 1)
Date: Fri, 16 Sep 2011 13:21:46 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

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 

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.


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?".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]