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

[Anthony Liguori <anthony@codemonkey.ws>]

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<paul@codesourcery.com>
>>>
>>>>>> 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
>
>