[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: Mon, 19 Sep 2011 09:05:17 -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/19/2011 02:26 AM, Jan Kiszka wrote:
On 2011-09-16 20:03, Anthony Liguori wrote:
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.

I thought a lot about this over the weekend and decided that I should go in a different direction based on this discussion.

Starting with the requirement that you have to be able to ask the device for an unambiguous reference to itself, I see two possible approaches:

1) Store the unambiguous reference within the child, derive unambiguous reference from the composition hierarchy.

2) Store a reference to the composition parent in the child. When asked for the unambiguous reference, use parent point to generate the reference.

These two approaches have subtle differences. For (1), all devices must be given globally unique names. For (2), all devices must be given names that are unique to its composition parent.

I really dislike having a 'Device *parent' pointer because I fear it will be abused, but there a number of elegant advantages to this model. For instance:

a) There is nothing special about user created devices. All user created devices sit on the root of the composition hierarchy. The names must be unique within that level of the composition tree. However, once you get one level down, it's a new namespace. This means you can achieve uniqueness without special characters or any of that nonsense.

b) We have proper path components without parsing a string and assigning special meaning to characters.

Point (b) is especially important because I spent a lot of time thinking about how to address Kevin's concerns about usability. I think we can significantly improve path usability by trying to do an unambiguous match from right-to-left on the path components. For instance, if you have:


You can do:

 -device isa-serial,bus=piix3  (or)
 -device isa-serial,bus=i440fx/piix3 (or)
 -device isa-serial,bus=/i440fx/piix3

The first two examples are relevant, but unambiguous paths, matched from right-to-left. The last example is an absolute path. Since the vast majority of the time, you have an unambiguous path by simple taking the last and possibly second-to-last path component, I think that most of the time you can use very short relative paths.

I think this ends up being a big usability improvement and the only way to implement this (1) is parsing device names and extract paths which is even more evil than having a composition parent link in the Device.

So I'm now rebasing my series and switching to this model. It's a rather significant change but I think I have a grip on how to do it.


Anthony Liguori

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.


reply via email to

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