Am 20.03.2012 18:14, schrieb Paul Brook: >> Make an ARMCPUClass that maps to the existing ARM support. Do *not* expose >> all of the different features as properties. Make ARMCPUClass abstract. >> >> Subclass ARMCPUClass for specific models, set default flags to implement >> the necessary logic. Expose tunables on a case-by-case basis (if there >> needs to be a 'neon' flag for cortex-a9, then make one, but don't make >> everything a flag just for the hell of it). > > As long as we can avoid the sort of duplication and redundant implementation > that the initial .feature patch introduced. If only having a neon knob on > some cores means we have to duplicate a whole bunch of boilerplate between > those cores then we're doing it wrong.
Allowing to parse cpu,+/-feature is what ARMCPU::features is for. object_new() creates an ARMCPU instance, initfn copies ARMCPUClass::features into ARMCPU::features, TBD sets/unsets feature flags. That's orthogonal to imperative vs. declarative and/or inheritence. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
