From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LULpt-0000UX-SS for qemu-devel@nongnu.org; Tue, 03 Feb 2009 09:01:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LULps-0000Tm-Tp for qemu-devel@nongnu.org; Tue, 03 Feb 2009 09:01:09 -0500 Received: from [199.232.76.173] (port=50558 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LULps-0000TT-7s for qemu-devel@nongnu.org; Tue, 03 Feb 2009 09:01:08 -0500 Received: from mr01.hansenet.de ([213.191.74.10]:35513) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LULpr-0002PP-Mc for qemu-devel@nongnu.org; Tue, 03 Feb 2009 09:01:07 -0500 Message-ID: <49884E19.9070909@exactcode.de> Date: Tue, 03 Feb 2009 15:00:57 +0100 From: Rene Rebe MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add multi-boot kernel loading support References: <49873680.2040603@exactcode.de> <200902031301.32385.paul@codesourcery.com> In-Reply-To: <200902031301.32385.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: Quoted-Printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Alexander Graf , paul@codesourcery.com Paul Brook wrote: > On Monday 02 February 2009, Rene Rebe wrote: >> Hi all, >> >> Alexander Graf implemented multi-boot kernel loading during >> his work to run Darwin inside Qemu/KVM. As the boot loader >> expects to load the kernel in an EFI environment a custom >> booter is used to load the kernel using a legacy BIOS. >> >> This is a port of the patch to the new extload / INT 19 >> machinery (including minor cleanups). >=20 > This is introducing quite a lot of nontrivial target code in a hard to=20 > understand and maintain way. This seems like a bad idea. >=20 > I suspect it would be better to implement this as an actual boot rom, a= nd have=20 > it read arguments from the firmware device. Ideally the same rom would = also=20 > cover the linux kernel case. Hm. As I'm not yet memorized the Qemu code and and build system maybe someone wants to shape the existing option rom code in the way envisioned to base this patch series on? Another option would also to apply (a cleaned up) version of the patch as it is quite local and intrusive code and someone else further re-factors it into an externally built option rom? Greetings, --=20 Ren=E9 Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name