From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpoVz-00063V-VN for qemu-devel@nongnu.org; Tue, 24 Jan 2012 17:06:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpoVw-0003sK-2E for qemu-devel@nongnu.org; Tue, 24 Jan 2012 17:06:55 -0500 Message-ID: <4F1F2B77.2020703@web.de> Date: Tue, 24 Jan 2012 23:06:47 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com> <1327433600-7403-28-git-send-email-aliguori@us.ibm.com> <4F1F0E2D.2020706@web.de> <4F1F12E7.2020309@us.ibm.com> <4F1F1C28.4040600@web.de> <4F1F1E91.50609@codemonkey.ws> <4F1F233B.8040804@web.de> <4F1F2875.3050509@codemonkey.ws> In-Reply-To: <4F1F2875.3050509@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB324FD58A42BA610B0E001CE" Subject: Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , "Michael S. Tsirkin" , Alexander Graf , qemu-devel@nongnu.org, Blue Swirl , =?ISO-8859-15?Q?Andreas_F=E4rber?= , qemu-ppc@nongnu.org, Paul Brook , Aurelien Jarno , Gerd Hoffmann This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB324FD58A42BA610B0E001CE Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2012-01-24 22:53, Anthony Liguori wrote: > On 01/24/2012 03:31 PM, Jan Kiszka wrote: >> On 2012-01-24 22:11, Anthony Liguori wrote: >>> On 01/24/2012 03:01 PM, Jan Kiszka wrote: >>>> On 2012-01-24 21:21, Anthony Liguori wrote: >>>>>> Also, I see a lot of programmatic initialization and a lot of >>>>>> repeating >>>>>> patterns (specifically regarding trivial class initialization) - >>>>>> there >>>>>> is no better alternative? >>>>> >>>>> Not really, no. It looks bad now because you have DeviceInfo still= =2E >>>>> Once DeviceInfo goes away, all of the initialization will happen in= >>>>> the >>>>> class_init function. >>>>> >>>>> The design of QOM is such that a lot of what was previously done vi= a >>>>> declarative structures is now done imperatively. But the code bloa= t >>>>> that came in this patch series will decrease significantly with the= >>>>> next >>>>> series as we eliminate DeviceInfo. >>>> >>>> Are there examples of fully converted devices to get an impression? >>> >>> https://github.com/aliguori/qemu/tree/qom-rebase.8 >>> >>> Has everything fully converted (including BusState). >>> >>> If you look at qdev.[ch], you'll notice the remaining qdev >>> infrastructure becomes greatly simplified. >> >> But I don't get yet why all these repeating initialization tasks need = to >> be open-coded instead of remaining declarative. >=20 > It would look like: >=20 > static void device_generic_class_init(ObjectClass *klass, void *data) > { > DeviceClass *dc =3D DEVICE_CLASS(klass); > DeviceTypeInfo *ti =3D data; >=20 > if (ti->reset) { > dc->reset =3D ti->reset; > } > if (ti->vmsd) { > dc->vmsd =3D ti->vmsd; > } > } >=20 > void device_type_register_static(DeviceTypeInfo *ti) > { > TypeInfo ti =3D { > .class_init =3D device_generic_class_init, > .class_data =3D ti, > // ... > } > type_register_static(&ti); > } >=20 > But I don't like this. The problem is that the declarative syntax we > have doesn't distinguish between "not-specified" and > "zero-initialized". That's surely solvable. > It's also tempting to just drop the if (ti->reset) > check but that means that you unconditionally override the base class > implementation even if it's not specified. That as well, just wrap this repeating pattern in a macro. >=20 > I don't see any tangible benefits to a declarative syntax except that i= t > makes it harder to get right because you have to write per-base class > initialization functions and it's very easy to get polymorphism wrong > there. Now you have to write way more derived class init functions - provided a base class is used more than once. >=20 > We're not talking about a code size difference. It's a wash in terms o= f > number of lines of code. We are. Code size will be smaller, so the number of lines. How much, that depends on the number of users per base class. >=20 > Imperative allows you to explicit zero-initialize, accept the previous > version (from the base class), or override with a new value. None of this is impossible with a declarative approach. Jan --------------enigB324FD58A42BA610B0E001CE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8fK3cACgkQitSsb3rl5xSNyACgqVTWn6ABtYnSha1S28wNfAja bcQAoNh5gZn3C1RESl+WbGwUX1jTrHhR =L7Op -----END PGP SIGNATURE----- --------------enigB324FD58A42BA610B0E001CE--