Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()

[Paolo Bonzini]

Il 13/04/2012 11:53, Peter Maydell ha scritto:
> On 13 April 2012 10:32, Paolo Bonzini <address@hidden> wrote:
>> Il 13/04/2012 11:09, Peter Maydell ha scritto:
>>> You're right in general that we should be modelling these as
>>> container objects (I posted a series the other week that starts
>>> to move in that direction by dropping the weird subclassing of
>>> the GIC.) But the overall container object for a cortex-a9 will
>>> still be an object whose number of exposed IRQ lines depends on
>>> a device parameter
>>
>> Yes, that would require a little more coding, just like the grlib.
> 
> Well, if we can do it then that's fine (assuming that the actual
> implementation doesn't look too dreadful and doesn't look wildly
> different from "number of irq lines is fixed").

Dreadful, no.  Different, no idea as of now. :)

>>> , and the GIC device must still have a number
>>> of exposed memory regions/input lines/output lines that depends
>>> on the number of CPUs, which is going to be a device parameter.
>>
>> That would be a device parameter of the SoC.  As long as the GIC
>> is only created after the device parameter has been set on the
>> parent, it can just read it from there.
> 
> I don't understand how this would work? The GIC can't read
> parameters from its parent, surely, that would be breaking
> encapsulation.

The GIC can have a (strongly-typed) backlink to the SoC, and can call
object_property_get on it.

>> (BTW perhaps it is cheating, but on the PC you just have
>> "-smp 4" for a four-core so it's not a device property).
> 
> I am assuming that '-smp 4' will eventually convert into
> setting a device property on something (probably on the
> QOM object which corresponds to the top level machine?).

Yeah, you would still know the type of that object though, and you would
still be able to retrieve the property.

>>> I'm not sure what your GICInterface children are?
>>
>> Those would model the GIC<->CPU interface memory regions.
> 
> MemoryRegions model memory regions :-) I'm not sure what
> more there is to do there.

MemoryRegion + how to create them + ops != MemoryRegion. :)

Paolo