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

[Alexander Graf <agraf@suse.de>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=ISO-8859-6-i, Size: 2101 bytes --]


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()

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.


Alex