[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v3 01/10] hw: arm_gic: Fix gic_set_irq handl
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [RFC PATCH v3 01/10] hw: arm_gic: Fix gic_set_irq handling |
Date: |
Thu, 19 Dec 2013 14:30:03 +0000 |
On 19 December 2013 14:26, Peter Crosthwaite
<address@hidden> wrote:
> 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?
That was the proposal, yes :-)
> 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.
Yeah, we could certainly do that. I was just hoping to avoid
doing a rework that created a pile of subclasses just for
another 11mpcore weirdness :-)
-- PMM