On 09/11/2012 02:23 PM, Andreas Färber wrote:
Am 07.09.2012 20:58, schrieb Scott Wood:
On 09/07/2012 03:08 AM, Alexander Graf wrote:
On 07.09.2012, at 01:15, Scott Wood <scottw...@freescale.com> wrote:
On 09/03/2012 01:44 AM, Bhushan Bharat-R65777 wrote:
Can we somehow pass this via qdev/varargs from machine emulation code
(hw/ppc/e500.c) ?
Possibly, though it may not be the best idea to express every single
aspect of intercomponent integration via qdev -- maybe that's best left
for things that are reasonably user-tweakable. If CCSR size is user
tweakable, it would be somewhere other than the PCI controller.
It depends. Qdev properties are basically object constructor
parameters. So if you were weiting C++ code and would have a
constructor that gets the size as argument, it would end up being
modeled as qdev property.
If however actual functionality differs, thus you would in OO speech
create a subclass / child class, then you are better off creating a
new device struct.
In this case, I'm not sure. They are different devices really, but
are close enough that the differences could be expressed through qdev
properties.
I wasn't suggesting that they be different devices. I was suggesting
that this isn't a property of the PCI controller, but rather of some
other entity to which the PCI controller connects. So maybe a reference
to the associated CCSR object would be a qdev parameter, but not the
size of that CCSR.
For a reference to another object a QOM link<> property would be
preferred over a static qdev property.
How does that work? Can we do RPC to other objects to access its CCSR
and/or enumerate the CCSR size? Or maybe even receive its memory api block?
Alex
