From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzZ9N-0005zJ-Mw for qemu-devel@nongnu.org; Mon, 20 Feb 2012 14:43:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzZ9L-0002Zs-Au for qemu-devel@nongnu.org; Mon, 20 Feb 2012 14:43:53 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:62458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzZ9L-0002Ze-8j for qemu-devel@nongnu.org; Mon, 20 Feb 2012 14:43:51 -0500 Received: by qabg40 with SMTP id g40so3476536qab.4 for ; Mon, 20 Feb 2012 11:43:50 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4F327CD4.1060502@codemonkey.ws> 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> <4F327CD4.1060502@codemonkey.ws> Date: Mon, 20 Feb 2012 19:43:50 +0000 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Anthony Liguori Cc: Peter Crosthwaite , aliguori@us.ibm.com, qemu-devel@nongnu.org, Alexander Graf , Paul Brook On 8 February 2012 13:47, Anthony Liguori wrote: > On 02/08/2012 06:41 AM, Alexander Graf wrote: >> Yeah, basically the variable flow goes: >> >> =C2=A0 vl.c -> =C2=A0machine_opts -> =C2=A0machine_init() -> =C2=A0devic= e properties -> >> =C2=A0device_init() > > And the rationale is that machine_init() will do nothing other than use Q= OM > primitives to create a set of expected devices and set up their propertie= s > such that a person (or management tool) could do everything that > machine_init() is doing. So I think this flow is wrong (and indeed I didn't implement it that way in my patches to add machine opts for kernel/initrd/dtb) -- the machine_init() shouldn't have to care about this because we don't want to have to modify a huge set of machine init functions every time we add an extra option that only the boot loader cares about. I don't particularly care how we QOMify arm_boot (it's not exactly at the top of my priority list demanding attention), I do care that (a) we have a sensible user-facing interface [ie command line options] and (b) vl.c can usefully just pass the information from those options straight to the boot loader code. -- PMM