From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCGFO-00012I-2V for qemu-devel@nongnu.org; Mon, 26 Mar 2012 16:10:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCGFF-00057Z-F3 for qemu-devel@nongnu.org; Mon, 26 Mar 2012 16:10:33 -0400 Received: from fmmailgate07.web.de ([217.72.192.248]:35908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCGFF-000571-57 for qemu-devel@nongnu.org; Mon, 26 Mar 2012 16:10:25 -0400 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate07.web.de (Postfix) with ESMTP id 587F5FAE4FF for ; Mon, 26 Mar 2012 22:10:23 +0200 (CEST) Message-ID: <4F70CD2A.3040802@web.de> Date: Mon, 26 Mar 2012 22:10:18 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1332727608-26523-1-git-send-email-liwp@linux.vnet.ibm.com> <4F705F08.4010002@siemens.com> <4F70A877.3060809@codemonkey.ws> <4F70C3E0.4000708@web.de> <4F70C4F6.8090900@codemonkey.ws> <4F70C55D.4030203@web.de> <4F70C5FA.4060605@codemonkey.ws> <4F70C726.9020504@web.de> <4F70C850.5030602@codemonkey.ws> In-Reply-To: <4F70C850.5030602@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig63A6A2E149B7290B6CAC99A7" Subject: Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Gavin Shan , "qemu-devel@nongnu.org" , Isaku Yamahata , Avi Kivity , Paolo Bonzini , Wanpeng Li This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig63A6A2E149B7290B6CAC99A7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2012-03-26 21:49, Anthony Liguori wrote: > On 03/26/2012 02:44 PM, Jan Kiszka wrote: >> On 2012-03-26 21:39, Anthony Liguori wrote: >>> On 03/26/2012 02:37 PM, Jan Kiszka wrote: >>>> On 2012-03-26 21:35, Anthony Liguori wrote: >>>>>>> Since this is an easily refactorable thing to look at later, I th= ink >>>>>>> we should >>>>>>> start with extracting the types. >>>>>> >>>>>> My worry is that those three refactorings set bad examples for >>>>>> others. >>>>>> So I'd like to avoid such back and forth if possible. >>>>> >>>>> I'm not really worried about it. It's so easier to refactor this >>>>> later. Why rush it now? >>>> >>>> You rush changing the current layout, not me. :) >>> >>> No, I'm trying to do incremental changes without boiling the ocean in= >>> the process. >>> >>> I think we all are in violent agreement about where we want to end up= >>> (as opaque types as possible). I don't want to hold back additional >>> refactoring on doing this right (and it's not just a matter of >>> malloc/free). >> >> Either I'm missing it in the code shuffling, or it's not part of this >> series: Can you point out where more that a forward reference and >> malloc/free is needed? >=20 > QOM is built around the concept that the type size is know (as is > GObject). type_initialize() assumes that the pointer passed is an > adequate size. >=20 > You would either need to move to a model where the memory was completel= y > owned by QOM (which would mean folding type_new into type_initialize) o= r > have a way to query instance size for a given type. >=20 > This would also mean that reference counting should be revisited > although with how dereferencing a parent affects the child. >=20 > It's not rocket science, but it's also something that needs to be done > carefully. But all this is only a problem for these three here (PIT, RTC, HPET) as their objects shall be embedded into the super-IO. If you only embed an object pointer, it shouldn't be an issue anymore, no? Also inheritance is not a problem here as we do not derive from the three types in question. If there is a super/sub-class relation, those need to share an internal header, of course. Jan --------------enig63A6A2E149B7290B6CAC99A7 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/ iEYEARECAAYFAk9wzSsACgkQitSsb3rl5xR8/ACeIWpPXKau3vtBh3Z5ae2ocbRq EC4AoLQBeLfah4PVJz1ieOlD+YL5Obk7 =qEpt -----END PGP SIGNATURE----- --------------enig63A6A2E149B7290B6CAC99A7--