From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsFDI-0006wA-6L for qemu-devel@nongnu.org; Tue, 31 Jan 2012 10:01:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsFDE-00085G-4R for qemu-devel@nongnu.org; Tue, 31 Jan 2012 10:01:40 -0500 Received: from thoth.sbs.de ([192.35.17.2]:26903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsFDD-000854-MM for qemu-devel@nongnu.org; Tue, 31 Jan 2012 10:01:36 -0500 Message-ID: <4F28024B.2020305@siemens.com> Date: Tue, 31 Jan 2012 16:01:31 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1327604460-31142-1-git-send-email-aliguori@us.ibm.com> <1327604460-31142-15-git-send-email-aliguori@us.ibm.com> <4F27FCD7.7050809@siemens.com> <4F27FFD3.9090107@codemonkey.ws> <4F280074.8010307@siemens.com> <4F280177.4030007@codemonkey.ws> In-Reply-To: <4F280177.4030007@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 14/15] i440fx: move bios loading to i440fx List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Anthony Liguori , "qemu-devel@nongnu.org" , Markus Armbruster , Avi Kivity , Paolo Bonzini On 2012-01-31 15:57, Anthony Liguori wrote: > On 01/31/2012 08:53 AM, Jan Kiszka wrote: >> On 2012-01-31 15:50, Anthony Liguori wrote: >>> On 01/31/2012 08:38 AM, Jan Kiszka wrote: >>>> On 2012-01-26 20:00, Anthony Liguori wrote: >>>>> --- >>>>> hw/pc.c | 70 ++++-------------------------------------------------- >>>>> hw/pc.h | 3 +- >>>>> hw/piix_pci.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- >>>>> sysemu.h | 2 - >>>>> 4 files changed, 79 insertions(+), 70 deletions(-) >>>> >>>> How does the ISA PC get its BIOS after this change? Or did that change >>>> in a step I miss right now? >>> >>> Oh, I broke it. I made no attempt to keep ISA PC working. >>> >>> The way I'd like to handle this is to introduce a ROM device so that this code >>> would be trivialized. >> >> Or just keep the common pc.c library as I voted for. It has its purpose, >> obviously. > > Coding sharing needs to happen through device sharing. Otherwise we'll be stuck > in the magic device creation through arbitrary functions rut that we currently > find ourselves in. Well, let's see what this will mean in practice. I'm sure that that there are steps in a PC construction that cannot be modeled reasonable even as pseudo devices but at still shared among boards. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux