On 19 December 2013 14:26, Peter Crosthwaite <peter.crosthwaite@xxxxxxxxxx> wrote: > On Thu, Dec 19, 2013 at 11:59 PM, Peter Maydell > <peter.maydell@xxxxxxxxxx> wrote: >> On 19 December 2013 13:49, Peter Crosthwaite >> <peter.crosthwaite@xxxxxxxxxx> wrote: >>> On Thu, Dec 19, 2013 at 7:03 PM, Peter Maydell <peter.maydell@xxxxxxxxxx> 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
