From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7W04-0001J5-0y for qemu-devel@nongnu.org; Tue, 13 Mar 2012 13:59:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7Vzy-0005tj-JX for qemu-devel@nongnu.org; Tue, 13 Mar 2012 13:59:07 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57859 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7Vzy-0005tN-AC for qemu-devel@nongnu.org; Tue, 13 Mar 2012 13:59:02 -0400 Message-ID: <4F5F8AE3.9080302@suse.de> Date: Tue, 13 Mar 2012 18:58:59 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1330893156-26569-1-git-send-email-afaerber@suse.de> <1331398436-20761-1-git-send-email-afaerber@suse.de> <1331398436-20761-3-git-send-email-afaerber@suse.de> <4F5F3E07.9070706@samsung.com> In-Reply-To: <4F5F3E07.9070706@samsung.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC v4 02/20] target-arm: Introduce QOM ARMCPUClass List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: i.mitsyanko@samsung.com Cc: Peter Maydell , Paul Brook , qemu-devel@nongnu.org, Anthony Liguori , Dmitry Solodkiy Am 13.03.2012 13:31, schrieb Igor Mitsyanko: > On 03/10/2012 08:53 PM, Andreas F=C3=A4rber wrote: >> diff --git a/target-arm/cpu.c b/target-arm/cpu.c >> new file mode 100644 >> index 0000000..dabc094 >> --- /dev/null >> +++ b/target-arm/cpu.c [...] >> +static void cpu_register(const ARMCPUInfo *info) >> +{ >> + TypeInfo type =3D { >> + .name =3D info->name, >> + .parent =3D TYPE_ARM_CPU, >> + .instance_size =3D sizeof(ARMCPU), >> + .class_size =3D sizeof(ARMCPUClass), >> + .class_init =3D arm_cpu_class_init, >> + .class_data =3D (void *)info, >> + }; >=20 > Are non-initialized members guaranteed to be zero here? I thought so for the C99-style struct initialization... I never ran into crashes while testing. Do we need static to be safe? >> + type_register_static(&type); >> +} >> + >=20 > Probably should be type_register() here in case these two will actually > differ in the future. My thinking was we don't need it here because the data (esp. strings) are not dynamically allocated. By comparison, I used type_register() for -cpudef in target-i386, I believe. But I really guess it's a bug that they're just an alias right now! ;) > If this information is of any help, we've got no problems when emulatin= g > ARM-based Exynos boards in QEMU with this whole patchset applied. Thanks a lot for testing! Have you thought about how to QOM'ify your boards? Mid-term I'd like to see an "exynos4210" object with the CPUs on it - maybe "cpu[0]" and "cpu[1]" child properties? Or "core[x]"? I had played with the sh7750 a bit on my branch but like the arm926 it's a single-core. 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