From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37117) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7uBR-0005l8-EP for qemu-devel@nongnu.org; Wed, 14 Mar 2012 15:48:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7uBM-0004se-Fm for qemu-devel@nongnu.org; Wed, 14 Mar 2012 15:48:28 -0400 Received: from mail-pz0-f47.google.com ([209.85.210.47]:51130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7uBM-0004sO-96 for qemu-devel@nongnu.org; Wed, 14 Mar 2012 15:48:24 -0400 Received: by dado14 with SMTP id o14so3622136dad.34 for ; Wed, 14 Mar 2012 12:48:22 -0700 (PDT) Message-ID: <4F60F602.6030905@codemonkey.ws> Date: Wed, 14 Mar 2012 14:48:18 -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> In-Reply-To: <4F61017F.5020301@gmail.com> 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: i.mitsyanko@samsung.com Cc: Igor Mitsyanko , qemu-devel@nongnu.org, d.solodkiy@samsung.com, Paolo Bonzini , Igor Mammedov , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= 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. At one point, I modeled this as a Vcc Pin with similar semantics except that instead of relying on a property accessor, the realize function would connect to the device's Vcc pin to the children's Vcc pins via a set of Wire objects (that just propagate Pin state). This later model is too low level IMHO. I think we should stick with the functional realize property which covers 99% of devices. For the 1%, we can use pins or just have additional properties as appropriate. Regards, Anthony Liguori