From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:34782)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1Rrq7B-0004bg-Ca
	for qemu-devel@nongnu.org; Mon, 30 Jan 2012 07:13:42 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1Rrq7A-0005Rn-8O
	for qemu-devel@nongnu.org; Mon, 30 Jan 2012 07:13:41 -0500
Received: from cantor2.suse.de ([195.135.220.15]:53032 helo=mx2.suse.de)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1Rrq7A-0005Rf-2M
	for qemu-devel@nongnu.org; Mon, 30 Jan 2012 07:13:40 -0500
Message-ID: <4F2688EB.8030809@suse.de>
Date: Mon, 30 Jan 2012 13:11:23 +0100
From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
MIME-Version: 1.0
References: <1327843531-32403-1-git-send-email-afaerber@suse.de>
	<1327843531-32403-7-git-send-email-afaerber@suse.de>
	<4F25FE36.90306@codemonkey.ws>
In-Reply-To: <4F25FE36.90306@codemonkey.ws>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH RFC 6/7] target-arm: Introduce QOM CPU and
 use for it CPUID lookup
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org, Paul Brook <paul@codesourcery.com>

Am 30.01.2012 03:19, schrieb Anthony Liguori:
> On 01/29/2012 07:25 AM, Andreas F=C3=A4rber wrote:
>> +/* CPU models */
>> +
>> +static void arm926_class_init(ObjectClass *klass, void *data)
>> +{
>> +    ARMCPUClass *k =3D ARM_CPU_CLASS(klass);
>> +
>> +    k->id =3D 0x41069265;
>> +}
>> +
>> +static void arm946_class_init(ObjectClass *klass, void *data)
>> +{
>> +    ARMCPUClass *k =3D ARM_CPU_CLASS(klass);
>> +
>> +    k->id =3D 0x41059461;
>> +}
>=20
> 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

--=20
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC=
rnberg