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? 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 > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
