qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 6/7] target-arm: Introduce QOM CPU and use f


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH RFC 6/7] target-arm: Introduce QOM CPU and use for it CPUID lookup
Date: Mon, 30 Jan 2012 13:11:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0

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



reply via email to

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