From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46782) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm6dh-00061T-K5 for qemu-devel@nongnu.org; Wed, 27 Jul 2011 12:07:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qm6dg-0005TD-Fb for qemu-devel@nongnu.org; Wed, 27 Jul 2011 12:07:17 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:54688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm6dg-0005SR-D7 for qemu-devel@nongnu.org; Wed, 27 Jul 2011 12:07:16 -0400 Received: by gwb19 with SMTP id 19so1384931gwb.4 for ; Wed, 27 Jul 2011 09:07:15 -0700 (PDT) Message-ID: <4E3037B0.2030409@codemonkey.ws> Date: Wed, 27 Jul 2011 11:07:12 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1311558293-5855-1-git-send-email-aliguori@us.ibm.com> <1311558293-5855-16-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 15/21] qom: add Device class List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Anthony Liguori , qemu-devel@nongnu.org On 07/27/2011 10:10 AM, Peter Maydell wrote: > On 25 July 2011 02:44, Anthony Liguori wrote: >> Device is meant to replace DeviceState as the root class for the device model. >> This is included here merely as a RFC. Device adds a couple of useful features. >> >> 1) Default hard reset. Device will literally call finalize on the object and >> then reinitialize it in place. This means that most devices don't have to >> worry about implementing reset logic. > > I like having a reset implemented as "just reinstantiate everything", but > this only really covers one of the different reset flavours ("simulation > reset", ie "give me a system in the same state as if I'd just started > qemu from scratch"). I think devices are still going to need to implement > "simulated reset", which is what they do when the core causes a simulated > reset signal to go active (and which ought really to be implemented by > having an incoming gpio signal 'reset'). reset is implemented as an edge of the realized property which is basically a pin. I view realized as the Vcc pin. In fact, I named it as such originally but thought that was too obscure :-) realize() is when Vcc goes high, unrealize/reset is when Vcc goes low. In terms of the very base Device class, there really is only one Vcc pin. For other types of devices, there might be multiple types of pins that have reset semantics. > The two are not always identical, > and you don't necessarily want to reset the whole of the model at once... > (And then some devices have another level of 'soft reset' which you get > by writing to one of its registers.) > > ...all of which isn't particularly relevant to the object/device model, > but I just wanted to say "reset isn't quite that simple" :-) Am very well aware, and tried to accommodate this. It's not modelled as a Pin because a Pin is a Device and it turns out that the notion of realized is also useful for non-Device objects. Regards, Anthony Liguori > -- PMM >