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

[Peter Crosthwaite <peter.crosthwaite@petalogix.com>]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

2012/2/9 Paul Brook <paul@codesourcery.com>

> > So if we consider this bootloader a device and its -dtb argument a
> property
> > of that device, then what you are implying is that every device property
> of
> > every device in a machine must be managed by the machine model? Isn't the
> > dynamic machine model work that is in progress is trying to get away the
> > approach where fixed machine models have to micromanage all their
> attached
> > devices? with the ultimate goal of -no-machine how will the bootloader
> get
> > this dtb argument?
>
> My expectation is that we have some way for the machine description to tag
> objects/properties that pap to the generic commandline options.  In the
> same
> way that we'd probably want to tag the default PCI bus, or UARTs for
> matching
> with the -serial commandline.  Some of these can be guessed, others you
> need
> the machine description to tell you.
>
> Paul
>

Ok, so it seems that for command line driven arguments the policy is with
standard arguments such as -dtb, the machine model must get it on the
device behalf and instantiate the device, and that fits in with this patch.

Its the other problem I am more worried about, i.e. when I -device
instantiate my bootloader with an existing machine how do I get my ram_size
and board_ID? The no machine opts for devices policy makes this impossible
such that I would have to pass in board_id and ram_size to
the boot-loader on the command line. Is there any acceptable way where the
machine model can make something globally available to devices for the
purpose of instantiating them with -device?

[-- Attachment #2: Type: text/html, Size: 2053 bytes --]