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

[Anthony Liguori]

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:

/i440fx
/i440fx/piix3
/i440fx/piix3/ide
/i440fx/slot[1.0]
/i440fx/slot[2.0]

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.

Regards,

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.
>
> Jan