From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7uOa-0000U6-1h for qemu-devel@nongnu.org; Wed, 14 Mar 2012 16:02:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7uOY-0008Ct-5Q for qemu-devel@nongnu.org; Wed, 14 Mar 2012 16:02:03 -0400 Received: from mail-pz0-f47.google.com ([209.85.210.47]:63459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7uOX-0008Cg-VR for qemu-devel@nongnu.org; Wed, 14 Mar 2012 16:02:02 -0400 Received: by dado14 with SMTP id o14so3639041dad.34 for ; Wed, 14 Mar 2012 13:02:00 -0700 (PDT) Message-ID: <4F60F934.3050509@codemonkey.ws> Date: Wed, 14 Mar 2012 15:01:56 -0500 From: Anthony Liguori 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> <4F60F80F.201@suse.de> In-Reply-To: <4F60F80F.201@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: i.mitsyanko@samsung.com, Igor Mitsyanko , qemu-devel@nongnu.org, d.solodkiy@samsung.com, Paolo Bonzini , Igor Mammedov On 03/14/2012 02:57 PM, Andreas Färber wrote: > 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ärber 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 the >>>> 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 think >>>> 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). >> >> I've explored a bunch of different models for this. My current thinking >> is a realized:bool property that when set, would call a realize() >> virtual method and when unset would call an unrealize() virtual method. >> 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. Yes, there's quite a lot of refactoring to get to a two stage recursive init. This is why realized isn't a part of QOM/qdev today. Regards, Anthony Liguori > > Andreas >