On Thu, Feb 20, 2014 at 01:58:06PM +0100, Paolo Bonzini wrote: > >@@ -151,6 +152,8 @@ extern PropertyInfo qdev_prop_arraylen; > > DEFINE_PROP(_n, _s, _f, qdev_prop_vlan, NICPeers) > > #define DEFINE_PROP_DRIVE(_n, _s, _f) \ > > DEFINE_PROP(_n, _s, _f, qdev_prop_drive, BlockDriverState *) > >+#define DEFINE_PROP_IOTHREAD(_n, _s, _f) \ > >+ DEFINE_PROP(_n, _s, _f, qdev_prop_iothread, IOThread *) > > #define DEFINE_PROP_MACADDR(_n, _s, _f) \ > > DEFINE_PROP(_n, _s, _f, qdev_prop_macaddr, MACAddr) > > #define DEFINE_PROP_LOSTTICKPOLICY(_n, _s, _f, _d) \ > > > > Should become a link sooner rather than later, but I'm not holding > the series for this.
I don't mind doing the work but I don't quite understand it: Links are a special QOM property type: a unidirectional relationship where the property holds the path and a reference to another object. I don't understand how the link's reference is released since object_property_add_link() internally doesn't pass a release() function pointer to object_property_add(). I also don't see callers explicitly calling object_unref() on their link pointer. Any ideas? I'm concerned that existing object_property_add_link() users are assigning the link pointer without incrementing the reference count like object_set_link_property() would. That sounds like a recipe for disaster if someone uses qom-set or equivalent. The rng device examples don't seem to help because there is no way to specify the rng backend via a qdev property (we always create a default backend). I need to be able to specify the object via a qdev property to the virtio-blk-pci device. Do I need to define a link<> qdev property: DEFINE_PROP_LINK("iothread", _state, _field.iothread, TYPE_IOTHREAD, IOThread *) Maybe this is the next step? Stefan