From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bphAq-0002hE-AR for qemu-devel@nongnu.org; Thu, 29 Sep 2016 15:39:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bphAk-0000Nv-Bw for qemu-devel@nongnu.org; Thu, 29 Sep 2016 15:39:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bphAk-0000Nr-5x for qemu-devel@nongnu.org; Thu, 29 Sep 2016 15:39:10 -0400 From: Markus Armbruster References: <1474893837-13010-1-git-send-email-jgross@suse.com> <1474893837-13010-3-git-send-email-jgross@suse.com> <1474967309.26376.12.camel@redhat.com> <1475162183.19923.7.camel@redhat.com> Date: Thu, 29 Sep 2016 21:39:05 +0200 In-Reply-To: <1475162183.19923.7.camel@redhat.com> (Gerd Hoffmann's message of "Thu, 29 Sep 2016 17:16:23 +0200") Message-ID: <87y42azeau.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 2/2] xen: add qemu device for each pvusb backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Juergen Gross , anthony.perard@citrix.com, xen-devel@lists.xensource.com, sstabellini@kernel.org, qemu-devel@nongnu.org Gerd Hoffmann writes: > Hi, > >> > Hmm, I think the xen core needs better QOM support ... >> > >> > struct XenDevice should have a DeviceState element, so it can be used as >> > device object directly instead of attaching a device object like >> > this ... >> >> Hmm, interesting idea. The device object could even be added in >> Xen common code if the backend is indicating the need for it via a >> special flag/field. I'll have a try. > > No, not optional. Just turn *all* xen devices into QOM objects. Yes, please. > XenDevice should probably a subclass of the base device object > (DeviceState), and all Xen backends (block, net, fb, pvusb, ...) > should be subclasses of XenDevice. > > The latter is probably how things are modeled already, just the QOM > object stuff is missing (register classes, macros to cast objects, ...) > because qdev (the QOM predecessor) didn't have that. > > Once this is in place you can simply use DEVICE(xendevice) to get the > DeviceState pointer. Related thread: qdevification of xen_disk From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [PATCH 2/2] xen: add qemu device for each pvusb backend Date: Thu, 29 Sep 2016 21:39:05 +0200 Message-ID: <87y42azeau.fsf@dusky.pond.sub.org> References: <1474893837-13010-1-git-send-email-jgross@suse.com> <1474893837-13010-3-git-send-email-jgross@suse.com> <1474967309.26376.12.camel@redhat.com> <1475162183.19923.7.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <1475162183.19923.7.camel@redhat.com> (Gerd Hoffmann's message of "Thu, 29 Sep 2016 17:16:23 +0200") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: "Qemu-devel" To: Gerd Hoffmann Cc: Juergen Gross , anthony.perard@citrix.com, xen-devel@lists.xensource.com, sstabellini@kernel.org, qemu-devel@nongnu.org List-Id: xen-devel@lists.xenproject.org Gerd Hoffmann writes: > Hi, > >> > Hmm, I think the xen core needs better QOM support ... >> > >> > struct XenDevice should have a DeviceState element, so it can be used as >> > device object directly instead of attaching a device object like >> > this ... >> >> Hmm, interesting idea. The device object could even be added in >> Xen common code if the backend is indicating the need for it via a >> special flag/field. I'll have a try. > > No, not optional. Just turn *all* xen devices into QOM objects. Yes, please. > XenDevice should probably a subclass of the base device object > (DeviceState), and all Xen backends (block, net, fb, pvusb, ...) > should be subclasses of XenDevice. > > The latter is probably how things are modeled already, just the QOM > object stuff is missing (register classes, macros to cast objects, ...) > because qdev (the QOM predecessor) didn't have that. > > Once this is in place you can simply use DEVICE(xendevice) to get the > DeviceState pointer. Related thread: qdevification of xen_disk