qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
Date: Wed, 08 Feb 2012 07:47:00 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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<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.


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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]