From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UlFsH-0005h2-Kt for qemu-devel@nongnu.org; Sat, 08 Jun 2013 05:55:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UlFsG-0003tR-CR for qemu-devel@nongnu.org; Sat, 08 Jun 2013 05:55:53 -0400 Received: from cantor2.suse.de ([195.135.220.15]:56673 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UlFsG-0003tL-3L for qemu-devel@nongnu.org; Sat, 08 Jun 2013 05:55:52 -0400 Message-ID: <51B2FFA0.6020403@suse.de> Date: Sat, 08 Jun 2013 11:55:44 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1370629140-30841-1-git-send-email-afaerber@suse.de> <1370629140-30841-3-git-send-email-afaerber@suse.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFT 2/5] virtio: Convert VirtioDevice to QOM realize/unrealize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Kevin Wolf , Anthony Liguori , anthony@codemonkey.ws, "Michael S. Tsirkin" , jlarrew@linux.vnet.ibm.com, qemu-devel@nongnu.org, "Aneesh Kumar K.V" , Stefan Hajnoczi , Amit Shah , Paolo Bonzini , fred.konrad@greensocs.com Hi, Am 08.06.2013 04:22, schrieb Peter Crosthwaite: > On Sat, Jun 8, 2013 at 4:18 AM, Andreas F=E4rber wro= te: >> diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c >> index dc6f4e4..409d315 100644 >> --- a/hw/9pfs/virtio-9p-device.c >> +++ b/hw/9pfs/virtio-9p-device.c [...] >> @@ -136,12 +138,16 @@ static Property virtio_9p_properties[] =3D { >> DEFINE_PROP_END_OF_LIST(), >> }; >> >> -static void virtio_9p_class_init(ObjectClass *klass, void *data) >> +static void virtio_9p_class_init(ObjectClass *oc, void *data) >> { >> - DeviceClass *dc =3D DEVICE_CLASS(klass); >> - VirtioDeviceClass *vdc =3D VIRTIO_DEVICE_CLASS(klass); >> + DeviceClass *dc =3D DEVICE_CLASS(oc); >> + VirtioDeviceClass *vdc =3D VIRTIO_DEVICE_CLASS(oc); >> + V9fsClass *v9c =3D VIRTIO_9P_CLASS(oc); >> + >> + v9c->parent_realize =3D dc->realize; >> + dc->realize =3D virtio_9p_device_realize; >> + >> dc->props =3D virtio_9p_properties; >> - vdc->init =3D virtio_9p_device_init; >> vdc->get_features =3D virtio_9p_get_features; >> vdc->get_config =3D virtio_9p_get_config; >> } >> @@ -151,6 +157,7 @@ static const TypeInfo virtio_device_info =3D { >> .parent =3D TYPE_VIRTIO_DEVICE, >> .instance_size =3D sizeof(V9fsState), >> .class_init =3D virtio_9p_class_init, >> + .class_size =3D sizeof(V9fsClass), >> }; >> >> static void virtio_9p_register_types(void) >> diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h >> index 1d6eedb..85699a7 100644 >> --- a/hw/9pfs/virtio-9p.h >> +++ b/hw/9pfs/virtio-9p.h >> @@ -227,6 +227,15 @@ typedef struct V9fsState >> V9fsConf fsconf; >> } V9fsState; >> >> +typedef struct V9fsClass { >> + /*< private >*/ >> + VirtioDeviceClass parent_class; >> + /*< public >*/ >> + >> + DeviceRealize parent_realize; >> +} V9fsClass; >> + >> + >=20 > If applied tree-wide this change pattern is going to add a lot of > boiler-plate to all devices. There is capability in QOM to access the > overridden parent class functions already, so it can be made to work > without every class having to do this save-and-call trick with > overridden realize (and friends). How about this: >=20 > diff --git a/hw/core/qdev.c b/hw/core/qdev.c > index 9190a7e..696702a 100644 > --- a/hw/core/qdev.c > +++ b/hw/core/qdev.c > @@ -37,6 +37,18 @@ int qdev_hotplug =3D 0; > static bool qdev_hot_added =3D false; > static bool qdev_hot_removed =3D false; >=20 > +void device_parent_realize(DeviceState *dev, Error **errp) > +{ > + ObjectClass *class =3D object_get_class(dev); > + DeviceClass *dc; > + > + class =3D object_class_get_parent(dc); > + assert(class); > + dc =3D DEVICE_CLASS(class); > + > + dc->realize(dev, errp); > +} > + >=20 > And child class realize fns can call this to realize themselves as the > parent would. Ditto for reset and unrealize. Then you would only need > to define struct FooClass when creating new abstractions (or virtual > functions if your C++). Indeed, if you check the archives you will find that I suggested the same in the context of ISA i8254/i8259 or CPUState. ;) Yet Anthony specifically instructed me to do it this way, referring to GObject. I then documented the expected process in qdev-core.h and object.h. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg