From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGoMY-0001W1-Nu for qemu-devel@nongnu.org; Fri, 21 Feb 2014 06:33:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGoMS-0002hK-Nt for qemu-devel@nongnu.org; Fri, 21 Feb 2014 06:33:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGoMS-0002hC-EE for qemu-devel@nongnu.org; Fri, 21 Feb 2014 06:33:44 -0500 Message-ID: <53073992.70803@redhat.com> Date: Fri, 21 Feb 2014 12:33:38 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1392900630-17608-1-git-send-email-stefanha@redhat.com> <1392900630-17608-6-git-send-email-stefanha@redhat.com> <5305FBDE.8030004@redhat.com> <20140221110317.GC17890@stefanha-thinkpad.redhat.com> In-Reply-To: <20140221110317.GC17890@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 5/6] iothread: add "iothread" qdev property type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Fam Zheng , qemu-devel@nongnu.org, Michael Roth Il 21/02/2014 12:03, Stefan Hajnoczi ha scritto: > 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: I won't claim I understand it 100% either, in fact it is why I don't think it should block the series. But we have actual link users and thus actual bugs, which we should fix. > 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? Bug, I guess. > 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. This is okay; object_property_add_link reference count takes ownership of the original value of the pointer. The real disaster is that links cannot be "locked" at realize time. For this to happen, links need to have a setter like object_property_add_str (not sure if they need a getter). > 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. You can do that, see virtio-rng-pci. It creates a link and forwards that to virtio-rng. > Do I need to define a link<> qdev property: > DEFINE_PROP_LINK("iothread", _state, _field.iothread, TYPE_IOTHREAD, IOThread *) Perhaps, but to do that we need to first fix object_property_add_link. Paolo