Am 30.01.2012 03:19, schrieb Anthony Liguori:
> On 01/29/2012 07:25 AM, Andreas Färber wrote:
>> +/* CPU models */
>> +
>> +static void arm926_class_init(ObjectClass *klass, void *data)
>> +{
>> + ARMCPUClass *k = ARM_CPU_CLASS(klass);
>> +
>> + k->id = 0x41069265;
>> +}
>> +
>> +static void arm946_class_init(ObjectClass *klass, void *data)
>> +{
>> + ARMCPUClass *k = ARM_CPU_CLASS(klass);
>> +
>> + k->id = 0x41059461;
>> +}
>
> In a situation like this, you probably want to make use of the
> class_data field in TypeInfo. You can use that to create a bunch of
> types based on a table.
That would work for this first trivial (which is why I picked it)
example, but a declarative table approach would not work well for things
that don't apply to all models.
Not to mention that I thought you wanted to have everything declarative
and might even be opposed to my name -> class_init table. ;)
A table approach for features would mean introducing a non-imperative
FEATURE() macro.
It might work to still include an optional class_init for those models
that need it (re 8/7). Will give it a try.
> Take a look at hw/eepro100.c for an example of this (although read the
> comment for the reference to class_data and why we can't use it until
> after the next series).
Thanks for the pointer, will check. (Hm, for 9/7 it appeared to work...)
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
