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
