[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 15/18] qom: optimize qdev_get_canonical_path usi
Re: [Qemu-devel] [PATCH 15/18] qom: optimize qdev_get_canonical_path using a parent link
Thu, 01 Dec 2011 07:38:49 -0600
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
On 12/01/2011 05:21 AM, Stefan Hajnoczi wrote:
On Wed, Nov 30, 2011 at 03:03:45PM -0600, Anthony Liguori wrote:
@@ -1210,6 +1210,9 @@ void qdev_property_add_child(DeviceState *dev, const char
qdev_property_add(dev, name, type, qdev_get_child_property,
NULL, NULL, child, errp);
+ g_assert(child->parent == NULL);
+ child->parent = dev;
The implications are:
1. A DeviceState must be a child or the root. It is not okay to create
a DeviceState and inquire its canonical path before making it a child in
2. A DeviceState can only be the child of one parent. Since
user-created devices are added to /peripheral or /peripheral-anon this
means that the /i440fx only has links to them, never a parent-child
/peripheral[-anon] are where user created devices live. Machine created devices
live directly off of /
Each "directory" ends up being a unique namespace. This ends up being a nice
way to support compatibly since we have so many namespace today.
I imagine, for instance, that we will end up with a /block directory too and
that is where blockdev objects will live.
Is this right?
+ /* Do not, under any circumstance, use this parent link below anywhere
+ * outside of qdev.c. You have been warned. */
+ DeviceState *parent;
It would be nice to explain why parent is private to qdev.c.
Composition is a unidirectional relationship. The parent pointer is there
simply as an optimization. I'll make the comment a big scarier :-)