Re: [Qemu-devel] [RFC PATCH v3 01/10] hw: arm_gic: Fix gic_set_irq handling

[Peter Crosthwaite]

On Thu, Dec 19, 2013 at 11:59 PM, Peter Maydell
<address@hidden> wrote:
> On 19 December 2013 13:49, Peter Crosthwaite
> <address@hidden> wrote:
>> On Thu, Dec 19, 2013 at 7:03 PM, Peter Maydell <address@hidden> wrote:
>>> My initial thought would be either to have if statements at the
>>> relevant points (which is how we've handled 11mpcore
>>> differences so far), or to bite the bullet and reflect the
>>> difference in the QOM class structure so we can use
>>> QOM methods [ie function pointers in the class struct].
>>>
>>
>> Even in the "if" approach its probably best to put the "is-11mpcore"
>> or "version" property in the class structure. So I think you want the
>> QOM class structure both ways.
>
> We have precedent elsewhere for having a "revision" property
> in the object struct rather than having subclasses per class, don't
> we? (arm_gic already has such a property, it's the 'revision' field.)

So given its already there, can you just cheat and get the revs right
and if on them?

Back to longer term though, I'm thinking of the sysbus EHCI as the
modern precedent. The small diffs between the incompatible
implementations are determined at class init time via which concrete
subclass you instantiated.

>
> Properties can't go in the class struct because by definition
> they can be set per-instance by the creator of the object.
>

You have multiple inherited classes. TYPE_ARM_GIC defines the class
property (maybe im looking for a better word than property here), and
TYPE_11MPCORE_GIC and friends set it in their class_init. Same as for
QOM abstract functions, just instead it's an abstract constant.

Regards,
Peter

> thanks
> -- PMM
>