qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]