From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rq3lc-00082F-Me for qemu-devel@nongnu.org; Wed, 25 Jan 2012 09:24:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rq3lY-0003gc-8g for qemu-devel@nongnu.org; Wed, 25 Jan 2012 09:24:04 -0500 Message-ID: <4F201077.1000906@web.de> Date: Wed, 25 Jan 2012 15:23:51 +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> <4F1F2B77.2020703@web.de> <4F1F38B6.7000506@codemonkey.ws> <4F1FBF31.2020002@web.de> <4F200AEE.20504@codemonkey.ws> In-Reply-To: <4F200AEE.20504@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBA6A76E477E31E53528AFEEE" 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) --------------enigBA6A76E477E31E53528AFEEE Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2012-01-25 15:00, Anthony Liguori wrote: > On 01/25/2012 02:37 AM, Jan Kiszka wrote: >> On 2012-01-25 00:03, Anthony Liguori wrote: >>> They're exactly the same size (16 lines). If you embed TypeInfo into= >>> DeviceTypeInfo, and introduce a Device specific type registration >>> function, then you could do: >>> >>> static DeviceTypeInfo my_device_type_info =3D { >>> .type.name =3D TYPE_MY_DEVICE, >>> .type.parent =3D TYPE_PARENT_DEVICE, >>> .reset =3D my_device_reset, >> >> And if you introduce some >> >> #define TYPE_UNIMPLEMENTED (void *)&dummy_variable >=20 > (void *) isn't compatible with integers or function pointers (at least > not in a portable way). The former is true, the latter not. However, if you use pointers in the TypeInfo structs consistently (const int * etc.), this issue should be solvable as well. >=20 > You would need to use type specific unimplemented mechanisms. >=20 >> >> you can easily express >> >> [.field =3D NULL] =3D> use parent >> .field =3D UNIMPLEMENTED =3D> don't run any handler >> >>> }; >>> >>> static void register_devices(void) >>> { >>> device_type_register_static(&my_device_type_info); >>> } >>> >>> Which admittedly saves 6 lines, but also is a big step backwards IMHO= =2E >>> Now you've got a lot of one-off functions which means you loose the >>> advantage of having everything work through the same infrastructure. >> >> Can't follow. Four lines >> >> [static inline] void device_type_register_static(DeviceTypeInfo *dt) >> { >> type_register_static(&dt->type); >> } >> >> are neither ugly nor complex. Rather, this helps concentrating effort = at >> _central_ places instead of decentralizing and duplicating lines like = in >> your imperative approach. That's the whole point: keep the common case= >> (derived classes) compact. >=20 > Send a patch. The infrastructure available should be enough to do > whatever you need to. >=20 > I'm not being dismissive, I've already spent a lot of time trying to > make it work and have convinced myself that it isn't workable. >=20 > If you can show a mechanism that works, I don't mind scripting a mass > conversion. I'm also fairly confident that a workable solution is goin= g > to be better than what we have. Well, I'm surely not happy having to go through all of the devices again, even if scripted (scripts tend to neglect some coding style rules e.g.). But if this change is in a hurry and my concern is the only one, then let it be. Jan --------------enigBA6A76E477E31E53528AFEEE 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/ iEYEARECAAYFAk8gEHoACgkQitSsb3rl5xRo2QCcCpZ28gYoEYVqn+9zzk9m7JLG 4NcAnj2VYfneCZCR+1aduOBnIr1DttOB =X/la -----END PGP SIGNATURE----- --------------enigBA6A76E477E31E53528AFEEE--