From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv6q0-0000wE-Nj for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:41:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv6pw-00050f-5K for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:41:28 -0500 Received: from cantor2.suse.de ([195.135.220.15]:53483 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv6pv-00050S-Oy for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:41:24 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=ISO-8859-6-i From: Alexander Graf In-Reply-To: <201202081228.00120.paul@codesourcery.com> Date: Wed, 8 Feb 2012 13:41:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1116A54F-BE1E-4620-BDC8-6B6A1A63D3B6@suse.de> References: <1328687721-16030-1-git-send-email-peter.crosthwaite@petalogix.com> <201202081139.49413.paul@codesourcery.com> <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: Paul Brook Cc: Peter Crosthwaite , peter.maydell@linaro.org, aliguori@us.ibm.com, qemu-devel@nongnu.org On 08.02.2012, at 13:27, Paul Brook wrote: >> 2012/2/8 Paul Brook >>=20 >>>>> I suspect we want to replace the arm_load_kernel call with an >>>>> arm_linux_loader device with appropriate properties. >>>>=20 >>>> Ok, so does this mean the machine model would still explicitly >>>> instantiate the bootloader device? >>>=20 >>> Yes. Bootloaders inherently have machine specific knowledge. They = need >>> to know ram location, board ID, secondary CPU boot protocols, etc.=20= >>> Requiring the user specify all these things separately from the rest = of >>> the machine description is IMO not acceptable. >>=20 >> 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. >=20 > Hmm, I suppose this might work. I'm not sure what you think the = benefit of=20 > this is though. Fact is the machine needs to have bootloader = awareness,=20 > whether it be instantating an object or setting magic variables. > Having devices rummage around in global state feels messy. I'd much = rather=20 > use actual properties on the device. IMO changing the bootloader is = similar=20 > complexity to (say) changing a UART. i.e. it's a board-level change = not an=20 > end-user level change. Board-level changes are something that will = happen=20 > after QOM conversion, i.e. when we replace machine->init with a board = config=20 > file. Yeah, basically the variable flow goes: vl.c -> machine_opts -> machine_init() -> device properties -> = device_init() So that the machine init function that creates the bootloader device = enumerates the machine_opts (just like is done in Peter's patches) and = then passes those on to the bootloader device as device properties. The rationale behind machine opts is that they're basically a dynamic = number of properties for the not-yet-existing machine object. Alex