From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCFd8-0003kf-0S for qemu-devel@nongnu.org; Mon, 26 Mar 2012 15:31:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCFd1-0000hX-GG for qemu-devel@nongnu.org; Mon, 26 Mar 2012 15:31:01 -0400 Received: from fmmailgate07.web.de ([217.72.192.248]:51448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCFd1-0000hE-60 for qemu-devel@nongnu.org; Mon, 26 Mar 2012 15:30:55 -0400 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate07.web.de (Postfix) with ESMTP id E068FFAE14B for ; Mon, 26 Mar 2012 21:30:52 +0200 (CEST) Message-ID: <4F70C3E0.4000708@web.de> Date: Mon, 26 Mar 2012 21:30:40 +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> In-Reply-To: <4F70A877.3060809@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC6EDCF22B6920D70AC824D64" 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: Anthony Liguori , Wanpeng Li , "qemu-devel@nongnu.org" , Isaku Yamahata , Avi Kivity , Paolo Bonzini , Gavin Shan This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC6EDCF22B6920D70AC824D64 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2012-03-26 19:33, Anthony Liguori wrote: > On 03/26/2012 07:20 AM, Jan Kiszka wrote: >> On 2012-03-26 04:06, Wanpeng Li wrote: >>> From: Anthony Liguori >>> >>> >>> This series aggressively refactors the PC machine initialization to b= e more >>> modelled and less ad-hoc. The highlights of this series are: >>> >>> 1) Things like -m and -bios-name are now device model properties >>> >>> 2) The i440fx and piix3 are now modelled in a thorough fashion >>> >>> 3) Most of the chipset features of the piix3 are modelled through c= omposition >>> >>> 4) i440fx_init is trivialized to creating devices and setting prope= rties >>> >>> 5) convert MemoryRegion to QOM >>> >>> 6) convert PCI host bridge to QOM >>> >>> The point (4) is the most important one. As we refactor in this fash= ion, >>> we should quickly get to the point where machine->init disappears com= pletely in >>> favor of just creating a handful of devices. >>> >>> The two stage initialization of QOM is important here. instance_init= () is when >>> composed devices are created which means that after you've created a = device, all >>> of its children are visible in the device model. This lets you set p= roperties >>> of the parent and its children. >>> >>> realize() (which is still called DeviceState::init today) will be cal= led right >>> before the guest starts up for the first time. >> >> While I see the value of the overall direction, I still disagree on >> making internal data structures of HPET, RTC and 8254 publicly >> available. That's a wrong step back. I'm sure there are smarter >> solutions, alse as there were some proposals back then in the original= >> thread. >=20 > I'm not fully decided myself. A couple things are clear to me though: >=20 > 1) We must expose type proper types in header files. We need there to = be a=20 > globally accessible RTCState type and functions that operate on it. I'm not sure what "proper type" means in this context, but I'm quite sure that there should be no need for poking into the internal of the class outside of mc146818rtc.c. We even abstracted the specifics of the RTC away when it is embedded into a super-IO and interacts with an HPET. If QOM requires such poking, then that requirement should be reassessed. >=20 > 2) We can simplify memory management by knowing the size of the type in= the=20 > header files too. Is this more than a malloc-free pair? >=20 > Since this is an easily refactorable thing to look at later, I think we= should=20 > 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. Jan --------------enigC6EDCF22B6920D70AC824D64 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/ iEYEARECAAYFAk9ww+MACgkQitSsb3rl5xS/HwCguynqwoDTOW43gTYjJcufyR/g ZooAoMpAnkzEZzLvXc2yO2wUSFinpW5N =lYDl -----END PGP SIGNATURE----- --------------enigC6EDCF22B6920D70AC824D64--