From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Cm5-0008LP-FQ for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:18:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4Clz-0002BS-C1 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:18:45 -0400 Received: from mail-gx0-f181.google.com ([209.85.161.181]:40660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Clz-0002BM-74 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:18:39 -0400 Received: by gxk9 with SMTP id 9so3255749gxk.12 for ; Thu, 15 Sep 2011 07:18:38 -0700 (PDT) Message-ID: <4E72093B.5060703@codemonkey.ws> Date: Thu, 15 Sep 2011 09:18:35 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <4E719F7C.10700@redhat.com> <4E71FD19.6050606@codemonkey.ws> <4E71FF3E.9040008@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , Paolo Bonzini , "Edgar E. Iglesias" On 09/15/2011 08:54 AM, Peter Maydell wrote: > On 15 September 2011 14:35, Paolo Bonzini wrote: >> It still holds, for two reasons. 1) The properties will be named >> differently for ISA and PCI versions, which is at the very least ugly; 2) if >> you want to save the property names for the ISA version, you need to >> duplicate the logic in NE2000 and PCI_NE2000. >> >> If we had C++ and templates, the problem would be much less pressing: just >> use inheritance for PCI and template for ISA vs. PCI. The code duplication >> at least is invisible to the programmer, it's only in the object files. > > Personally I think the right way to approach this sort of thing is going > to be to have some sort of special purpose language for declaring > devices (and their composition, wiring, interfaces, properties) which is > used to generate all the tedious boilerplate code. Actual interesting code > (corresponding roughly to "method bodies") stays as C functions in > standard C source files. > > It's already the case with existing qdev that just instantiating and > setting the properties for a qdev device is sufficiently tedious > that we have lots of utility foo_create() functions scattered around > the codebase. I don't think QOM is going to be any better there. > > More generally, I don't think we should let our conceptual model of > how devices are composed and connected be warped by whether you can > implement it with C-and-a-pile-of-macros or not. I think there are two real discussions happening here. One is how to model and one is what is the right representation of that modelling. I think Paolo is strongly advocating a non-OO model that uses the command pattern to establish most of the relationships. Maybe one level of inheritance is used just to provide the right infrastructure for the objects to have properties but that's inheritance for functionality verses modelling. I'm advocating a strict OO model. I'm not normally a fan of OO based design but I think it fits a device model pretty well because it's such a concrete hierarchy. All of the objects we create really correspond to real world objects and the inheritance relationships are pretty darn obvious. When you're holding a PCI NE2000 card in your hand, there's simply no doubt that it is-a PciDevice. And you can look at the PCB and see that it has-a NE2K chip on it. Regards, Anthony Liguori > > -- PMM >