From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34352 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnqAt-0006ws-Kd for qemu-devel@nongnu.org; Tue, 24 Aug 2010 05:52:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnqAs-0005Ug-IT for qemu-devel@nongnu.org; Tue, 24 Aug 2010 05:52:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59867) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnqAs-0005UR-C5 for qemu-devel@nongnu.org; Tue, 24 Aug 2010 05:52:10 -0400 Message-ID: <4C73963B.4010805@redhat.com> Date: Tue, 24 Aug 2010 12:51:55 +0300 From: Avi Kivity 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> <4C727C43.2040704@codemonkey.ws> <4C727EF5.6060402@redhat.com> <4C72851E.50405@codemonkey.ws> <4C72869A.3030302@redhat.com> <4C728A12.2090006@codemonkey.ws> <4C72904F.2030103@redhat.com> <4C729B80.3090604@codemonkey.ws> In-Reply-To: <4C729B80.3090604@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , "Liu >> \"Liu, Jinsong\"" , qemu-devel , Markus Armbruster , Paul Brook On 08/23/2010 07:02 PM, Anthony Liguori wrote: > On 08/23/2010 10:14 AM, Avi Kivity wrote: >> On 08/23/2010 05:47 PM, Anthony Liguori wrote: >>> >>>>> >>>>> Devices can contain references to structs and objects. If a >>>>> Device contains a reference to an object, the object should be >>>>> stored in a BusState which is a container of Devices. Therefore, >>>>> the object should inherit from Device. >>>> >>>> I disagree. It's up to the author to decide whether to split a >>>> Device into 1 or 15 objects. >>>> >>>> If one of the other objects is also a subclass of DeviceState, then >>>> you're probably violating that DeviceState's contract. But that's >>>> a different (and trivial) matter. >>>> >>>> (side point: in C no objects have constructors and methods. in C++ >>>> all objects have constructors and methods, even PODs) >>> >>> Things that inherit from DeviceState have ctors/dtors. Things that >>> don't end up inventing their own and probably will do so poorly. >> >> you mean misimplement other_state_init(OtherState *) and >> other_state_destroy(OtherState *)? > > And hot plug, save/restore, properties, and all of the other things > that go along with qdev. > > Hot plug is a good example of how easy it is to screw this up by not > having the right hooks being propagated through the device model. Come on now, this is all trivial. If you get a qdev callback you just propagate it to all objects that need it. Practically all non-trivial devices need to do it. For example if you remove gpio from qdev, then a device that has an array of gpios will have un-embedded objects in its DeviceState. Look at ivshmem.c with its non-embedded Peer objects. -- error compiling committee.c: too many arguments to function