From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm5kr-0003YF-0h for qemu-devel@nongnu.org; Wed, 27 Jul 2011 11:10:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qm5kp-0007UO-UU for qemu-devel@nongnu.org; Wed, 27 Jul 2011 11:10:36 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:56362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm5kp-0007U3-Ry for qemu-devel@nongnu.org; Wed, 27 Jul 2011 11:10:35 -0400 Received: by yia25 with SMTP id 25so1332793yia.4 for ; Wed, 27 Jul 2011 08:10:34 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1311558293-5855-16-git-send-email-aliguori@us.ibm.com> References: <1311558293-5855-1-git-send-email-aliguori@us.ibm.com> <1311558293-5855-16-git-send-email-aliguori@us.ibm.com> Date: Wed, 27 Jul 2011 16:10:33 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 15/21] qom: add Device class List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On 25 July 2011 02:44, Anthony Liguori wrote: > Device is meant to replace DeviceState as the root class for the device m= odel. > This is included here merely as a RFC. =C2=A0Device adds a couple of usef= ul features. > > 1) Default hard reset. =C2=A0Device will literally call finalize on the o= bject and > =C2=A0 then reinitialize it in place. =C2=A0This means that most devices = don't have to > =C2=A0 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'). 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" :-) -- PMM