From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzZHK-0002VJ-El for qemu-devel@nongnu.org; Mon, 20 Feb 2012 14:52:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzZHF-0004Id-Ui for qemu-devel@nongnu.org; Mon, 20 Feb 2012 14:52:06 -0500 Received: from cantor2.suse.de ([195.135.220.15]:32995 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzZHF-0004IS-Jh for qemu-devel@nongnu.org; Mon, 20 Feb 2012 14:52:01 -0500 Message-ID: <4F42A45E.5010608@suse.de> Date: Mon, 20 Feb 2012 20:51:58 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= 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> <4F327CD4.1060502@codemonkey.ws> In-Reply-To: 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: Peter Maydell Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, Alexander Graf , Peter Crosthwaite , Paul Brook Am 20.02.2012 20:43, schrieb Peter Maydell: > 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: >>> >>> vl.c -> machine_opts -> machine_init() -> device properties -> >>> device_init() >> >> And the rationale is that machine_init() will do nothing other than us= e QOM >> primitives to create a set of expected devices and set up their proper= ties >> such that a person (or management tool) could do everything that >> machine_init() is doing. >=20 > So I think this flow is wrong (and indeed I didn't implement it that wa= y in > my patches to add machine opts for kernel/initrd/dtb) -- the machine_in= it() > shouldn't have to care about this because we don't want to have to modi= fy > a huge set of machine init functions every time we add an extra option > that only the boot loader cares about. >=20 > 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. A QOM'ified arm_boot could get a "virtual" callback method to check the QemuOpts command line args. That way derived classes can decide what additional options to accept. An alternative would be to expect QOM properties of the same name as the command line parameters and fail if there isn't one of that name. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg