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

[Paul Brook]

> 2012/2/8 Paul Brook <address@hidden>
> 
> > > > 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.

Paul