On 8 February 2012 13:47, Anthony Liguori <anth...@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. -- PMM
