qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 07/18] qom: add link properties


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 07/18] qom: add link properties
Date: Thu, 01 Dec 2011 07:44:19 -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, Avi Kivity wrote:
On 11/30/2011 11:03 PM, Anthony Liguori wrote:
Links represent an ephemeral relationship between devices.  They are meant to
replace the qdev concept of busses by allowing more informal relationships
between devices.

So, links are equivalent to pointers?

Yup. Once we have qom inheritance (next stage), we can have a link<PCIDevice> property and you'll be able to set it to an E1000State with the appropriate casting and error checking taking place.

Links are fairly limited in their usefulness without implementing QOM-style
subclassing and interfaces.


+static void qdev_get_link_property(DeviceState *dev, Visitor *v, void *opaque,
+                                   const char *name, Error **errp)
+{
+    DeviceState **child = opaque;
+    gchar *path;
+
+    if (*child) {
+        path = qdev_get_canonical_path(*child);
+        visit_type_str(v,&path, name, errp);
+        g_free(path);
+    } else {
+        path = (gchar *)"";

If gchar != char, this is wrong.  Also, you're converting a const
pointer into a non-const pointer, discarding type safety.

I'll address this later in the thread.

+        visit_type_str(v,&path, name, errp);
+    }

Shouldn't this be visit_type_link()?

link isn't a primitive type for visitors. visit_type_link() would just call visit_type_str() so I don't think there's a ton of value in introducing the extra layer.

The accessors are the only places that should be marshaling links.

Regards,

Anthony Liguori






reply via email to

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