Re: [Qemu-devel] [PATCH v3 5/6] iothread: add "iothread" qdev property type

[Stefan Hajnoczi]

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