qemu-devel
[Top][All Lists]
Advanced

[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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 15/18] qom: optimize qdev_get_canonical_path using a parent link
Date: Thu, 01 Dec 2011 07:38:49 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) 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 
*name,
      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
    the graph.

Correct.


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

Correct.

/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 :-)

Regards,

Anthony Liguori





reply via email to

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