From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41109)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1bpd4b-0001XA-EZ
	for qemu-devel@nongnu.org; Thu, 29 Sep 2016 11:16:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1bpd4V-000471-FK
	for qemu-devel@nongnu.org; Thu, 29 Sep 2016 11:16:32 -0400
Received: from mx1.redhat.com ([209.132.183.28]:33812)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1bpd4V-00046j-9p
	for qemu-devel@nongnu.org; Thu, 29 Sep 2016 11:16:27 -0400
Message-ID: <1475162183.19923.7.camel@redhat.com>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Thu, 29 Sep 2016 17:16:23 +0200
In-Reply-To: <fc223e2a-bb6c-55ad-f1c1-ca55a118fa63@suse.com>
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>
	<fc223e2a-bb6c-55ad-f1c1-ca55a118fa63@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 2/2] xen: add qemu device for each pvusb
 backend
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Juergen Gross <jgross@suse.com>
Cc: qemu-devel@nongnu.org, xen-devel@lists.xensource.com, anthony.perard@citrix.com, sstabellini@kernel.org

  Hi,

> > Hmm, I think the xen core needs better QOM support ...
> >=20
> > struct XenDevice should have a DeviceState element, so it can be used a=
s
> > device object directly instead of attaching a device object like
> > this ...
>=20
> 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.

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.

cheers,
  Gerd