From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7uJo-0004ki-Ts for qemu-devel@nongnu.org; Wed, 14 Mar 2012 15:57:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7uJn-0006yX-5Q for qemu-devel@nongnu.org; Wed, 14 Mar 2012 15:57:08 -0400 Received: from cantor2.suse.de ([195.135.220.15]:58004 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7uJm-0006yJ-Sh for qemu-devel@nongnu.org; Wed, 14 Mar 2012 15:57:07 -0400 Message-ID: <4F60F80F.201@suse.de> Date: Wed, 14 Mar 2012 20:57:03 +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> <4F61017F.5020301@gmail.com> <4F60F602.6030905@codemonkey.ws> In-Reply-To: <4F60F602.6030905@codemonkey.ws> 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: Anthony Liguori Cc: i.mitsyanko@samsung.com, Igor Mitsyanko , qemu-devel@nongnu.org, d.solodkiy@samsung.com, Paolo Bonzini , Igor Mammedov Am 14.03.2012 20:48, schrieb Anthony Liguori: > On 03/14/2012 03:37 PM, Igor Mitsyanko wrote: >> On 13.03.2012 3:13 PM, Andreas F=C3=A4rber wrote: >> >>> In SysBusDeviceClass etc. we use the specific object type, too. >>> Obviously my CPU is the first "new" QOM type, so we can go different >>> ways if we want to. As long as it's a CPU-specific mechanism, using t= he >>> specific type avoids some casts. >>> >>>> 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 thin= k >>> it belongs into Object at least. Maybe DeviceState. Anthony? Paolo? >>> >> >> We can have a special object for this, let's call it ResetLine for >> example, with >> methods ResetLine::connect, ResetLine::assert or something like that. >> Different >> ResetLine objects could trigger reset of different sets of subdevices, >> just like >> real hardware can have several reset types (for example, STM32 has 3 >> different >> reset types). >=20 > I've explored a bunch of different models for this. My current thinkin= g > is a realized:bool property that when set, would call a realize() > virtual method and when unset would call an unrealize() virtual method.= =20 > The default implementation of [un]realize() would propagate the change > to all composition children. I've found that model not to work with today's qdev remainders: We often have a dependency tree of initfn and init a.k.a. realize functions, so that we can't clearly separate between the two to do recursive processing. Unless we do a three-stage initialization of Object::initfn, what-is-now-DeviceState::init, Object::realize. 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