From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7REk-0005vC-TS for qemu-devel@nongnu.org; Tue, 13 Mar 2012 08:54:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7REe-0000Zl-L6 for qemu-devel@nongnu.org; Tue, 13 Mar 2012 08:53:58 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36465 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7REe-0000ZT-CS for qemu-devel@nongnu.org; Tue, 13 Mar 2012 08:53:52 -0400 Message-ID: <4F5F435E.3080603@suse.de> Date: Tue, 13 Mar 2012 13:53:50 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1330893156-26569-1-git-send-email-afaerber@suse.de> <1331346496-10736-1-git-send-email-afaerber@suse.de> <1331346496-10736-45-git-send-email-afaerber@suse.de> <4F5DC41F.10903@redhat.com> <4F5F39DD.5040308@suse.de> <4F5F3B7C.8030509@redhat.com> In-Reply-To: <4F5F3B7C.8030509@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Igor Mammedov , qemu-devel@nongnu.org, Anthony Liguori Am 13.03.2012 13:20, schrieb Paolo Bonzini: > Il 13/03/2012 13:13, Andreas F=C3=A4rber ha scritto: >>> It will be easier to generalize later qdev code and not make special >>> case when adding cpus. >> >> I never heard anyone wanting to generalize reset so far. I don't think >> it belongs into Object at least. Maybe DeviceState. Anthony? Paolo? >=20 > I believe long term we want CPUs to become a DeviceState. For now, I > think Andreas's prototype is fine. I have prepared $(qom-obj-twice-y) to allow for: #ifdef CONFIG_SOFTMMU .parent =3D TYPE_DEVICE, // or TYPE_SYS_BUS_DEVICE #else .parent =3D TYPE_OBJECT, #endif So far it was not needed. :) > Methods should not take a superclass > argument in general. So to clarify, this is pro CPUState? >> This series is taking much too long to move forward (the QOM "steam" >> seems to be gone?) and I'm worried that introducing much more basic=20 >> infrastructure will make review and applying even slower, cf.=20 >> object_class_foreach_ordered()/_get_list(). >=20 > Agreed, this series looks more or less good (and mostly mechanical > anyway). Thanks. > Is it an RFC or what? :) I wonder if reviewers are put off by > the subject. The implied RFC is, are we okay with reusing "CPUState" this way? Or does someone - last call! - have a better identifier name? Getting this series merged either means coordinating the PULL with a maintainer so that no merge conflicts arise in-flight, or having the maintainer re-run the commit-creating script himself. 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