From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv6d8-0003b7-Uj for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:28:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv6d6-0001pN-PG for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:28:10 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:64147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv6d6-0001p4-Ku for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:28:08 -0500 From: Paul Brook Date: Wed, 8 Feb 2012 12:27:58 +0000 References: <1328687721-16030-1-git-send-email-peter.crosthwaite@petalogix.com> <201202081139.49413.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <201202081228.00120.paul@codesourcery.com> Subject: Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: peter.maydell@linaro.org, aliguori@us.ibm.com, qemu-devel@nongnu.org, agraf@suse.de > 2012/2/8 Paul Brook > > > > > I suspect we want to replace the arm_load_kernel call with an > > > > arm_linux_loader device with appropriate properties. > > > > > > Ok, so does this mean the machine model would still explicitly > > > instantiate the bootloader device? > > > > Yes. Bootloaders inherently have machine specific knowledge. They need > > to know ram location, board ID, secondary CPU boot protocols, etc. > > Requiring the user specify all these things separately from the rest of > > the machine description is IMO not acceptable. > > So what im suggesting here is that machines export these properties to a > globally accessible location. Perhaps via the machine opts mechanism? Then > we are in a best of both worls situation where machine models do not need > bootloader awareness yet bootloaders can still query qemu for ram_size, > smp#, board_id and friends. Hmm, I suppose this might work. I'm not sure what you think the benefit of this is though. Fact is the machine needs to have bootloader awareness, whether it be instantating an object or setting magic variables. Having devices rummage around in global state feels messy. I'd much rather use actual properties on the device. IMO changing the bootloader is similar complexity to (say) changing a UART. i.e. it's a board-level change not an end-user level change. Board-level changes are something that will happen after QOM conversion, i.e. when we replace machine->init with a board config file. Paul