Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition

["Andreas Färber" <afaerber@suse.de>]

Am 20.02.2012 20:43, schrieb Peter Maydell:
> On 8 February 2012 13:47, Anthony Liguori <anthony@codemonkey.ws> 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 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.
> 
> 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.

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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg