From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54948 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnXOW-00054k-R6 for qemu-devel@nongnu.org; Mon, 23 Aug 2010 09:49:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnXOR-0002wt-Ma for qemu-devel@nongnu.org; Mon, 23 Aug 2010 09:49:00 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:34877) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnXOR-0002wn-Je for qemu-devel@nongnu.org; Mon, 23 Aug 2010 09:48:55 -0400 Received: by ywa6 with SMTP id 6so2217891ywa.4 for ; Mon, 23 Aug 2010 06:48:55 -0700 (PDT) Message-ID: <4C727C43.2040704@codemonkey.ws> Date: Mon, 23 Aug 2010 08:48:51 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup References: <4C6D86F9.3010602@codemonkey.ws> <4C6D98E7.9020109@codemonkey.ws> <4C6DA75D.40303@codemonkey.ws> <4C6ECBB7.7060608@codemonkey.ws> <4C718865.7010807@redhat.com> <4C719080.4030202@codemonkey.ws> <4C720B1F.3030206@redhat.com> <4C727646.3040903@codemonkey.ws> <4C727ACC.7080501@redhat.com> In-Reply-To: <4C727ACC.7080501@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , "Liu >> \"Liu, Jinsong\"" , qemu-devel , Markus Armbruster , Paul Brook On 08/23/2010 08:42 AM, Avi Kivity wrote: >>> GPIO is just one way for a device to talk, same as >>> (*bus)_phys_memory_rw() or its netdev or its chardev or its timers. >>> It doesn't need to have special status within DeviceState, but it >>> doesn't hurt so much that I can tell. >> >> Everything extra hurts when you're trying to move code in to a >> library with unit tests covering the functionality :-) > > Sure, it's a worthy cleanup. But it's not a reason to go to DEFCON 1. I think you're reading too much into my late night rantings ;-) >>>> But being able to associate timers with devices seems like a very >>>> good idea to me because it means that you can see which devices are >>>> registering timers. >>> >>> You might also have the timers auto-cancelled and auto-destroyed on >>> device removal. But the whole thing seems like a minor coding issue >>> rather than something fundamental. >> >> The fundamental issue is: every function (minus trivial ones) in the >> device models code should have a state reference. That state >> reference should inherit from a DeviceState. If this statement isn't >> true, then the device has been modelled in qdev incorrectly. >> >> Using this test, quite a lot of the "converted" devices are being >> modelled incorrectly. > > Is a "state reference" allowed to have a pointer to the state, or > reach it in some other way (for example, static storage for singleton > devices)? No. If this was C++, then the statement would be: device have to be implemented in terms of objects that inherit from Device. Device is our common base object. > Isn't "save/restore works" an equivalent statement to "device state is > reachable from the DeviceState"? I'm not sure I can connect the dots here as I'm not sure what follows if your assertion is true. Regards, Anthony Liguori