From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv7rf-0000YZ-Cl for qemu-devel@nongnu.org; Wed, 08 Feb 2012 08:47:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv7rW-0003Qn-3k for qemu-devel@nongnu.org; Wed, 08 Feb 2012 08:47:15 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:53768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv7rV-0003Qd-VN for qemu-devel@nongnu.org; Wed, 08 Feb 2012 08:47:06 -0500 Received: by pbbro12 with SMTP id ro12so682305pbb.4 for ; Wed, 08 Feb 2012 05:47:04 -0800 (PST) Message-ID: <4F327CD4.1060502@codemonkey.ws> Date: Wed, 08 Feb 2012 07:47:00 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1328687721-16030-1-git-send-email-peter.crosthwaite@petalogix.com> <201202081139.49413.paul@codesourcery.com> <201202081228.00120.paul@codesourcery.com> <1116A54F-BE1E-4620-BDC8-6B6A1A63D3B6@suse.de> In-Reply-To: <1116A54F-BE1E-4620-BDC8-6B6A1A63D3B6@suse.de> Content-Type: text/plain; charset=ISO-8859-6-I; format=flowed Content-Transfer-Encoding: 7bit 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: Alexander Graf Cc: Peter Crosthwaite , peter.maydell@linaro.org, aliguori@us.ibm.com, Paul Brook , qemu-devel@nongnu.org On 02/08/2012 06:41 AM, Alexander Graf wrote: > > On 08.02.2012, at 13:27, Paul Brook wrote: > >>> 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. > > > Yeah, basically the variable flow goes: > > vl.c -> machine_opts -> machine_init() -> device properties -> device_init() And the rationale is that machine_init() will do nothing other than use QOM primitives to create a set of expected devices and set up their properties such that a person (or management tool) could do everything that machine_init() is doing. Down the road, we'll introduce a -no-machine property that will not run machine_init() at all. The reason to use machine_opts instead of a global is that we have mechanisms to query the existence of machine_opts, display inline help, introspect them in a running QEMU instance, etc. > > 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. Yes, we could also model machine_init() as an object, but in general, it should strictly be a super object that composes together other objects and forwards properties. We don't want any actually logic to live in the machines. Regards. Anthony Liguori > > > Alex > >