From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaSJC-00078X-Kv for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:22:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaSJ8-0005Jb-77 for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:22:14 -0500 Received: from mail-yx0-f173.google.com ([209.85.213.173]:47043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaSJ8-0005JV-3Z for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:22:10 -0500 Received: by yenm6 with SMTP id m6so6358854yen.4 for ; Tue, 13 Dec 2011 05:22:09 -0800 (PST) Message-ID: <4EE7517D.2060709@codemonkey.ws> Date: Tue, 13 Dec 2011 07:22:05 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <201112130447.58486.paul@codesourcery.com> In-Reply-To: <201112130447.58486.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Paul Brook Cc: Peter Maydell , Anthony Liguori , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" On 12/12/2011 10:47 PM, Paul Brook wrote: >> The full set of devices names and properties used in this example are >> below: >> >> Type: I440FX >> Is-a: Device >> Implements: PciBus >> Name: i440fx >> Properties: >> piix3: Composition >> slot[1.0]: Backlink >> >> Type: PIIX3 >> Isa-a: PciDevice >> Implements: IsaBus >> Name: i440fx::piix3 >> Properties: >> i8042: Composition >> bus: Backlink (inherited from PciDevice) >> >> Type: I8042 >> Isa-a: Device >> Implements: Ps2Controller >> Name: i440fx::piix3::i8042 >> Properties: >> aux: Backlink > > I haven't looks at the patches in detail, but your description looks fairly > dubious in its current form. This is an old thread. A few things have evolved since then. > > Is the type of piix3::bus a typo? I think this should be Backlink. Yup. It's now link. > > What is the difference between "Is-a" and "Implements"? It's multiple inheritance but interfaces (implements) cannot carry state which avoids an inheritance diamond problem. This is the inheritance model used by Java, C#, and glib. > It sounds like some > form of multiple inheritance, but it's unclear to me which should be the > primary type. For PCI host bridges like the i440fx we currently have to split > them into two, one fot the host bus and the other for the PCI bus. It feels > like if we design the model properly this should no longer be necessary. Yes, that's exactly what this solves. I think we could probably make i440fx is-a PCIDevice that implements a PciBus. It's the same thing we would do with a PCI Bridge. > I'm not so sure we should have Is-a at all. A point that has been repeatedly brought up is that you can avoid primary inheritance and just rely on composition using composed interfaces as your communication vehicle. I think in some cases, that will make sense, and the object model allows that. > Isn't the point of replacing the > bus/device hierachy with a set of links that devices don't follow a simple > tree structure? It's fairly common for the tree branches to merge back > together when a single device communicates via multiple busses. Yes, but don't confuse the inheritance tree with the device graph. > It's somewhat unlear what the purpose of composition is. Using composition > for piix4::piiix and piix3::i8042 seems wrong. In fact piix3 shouldn't have > any knowledge of i8042 at all, it's just annother random ISA device. i8042 is not a random ISA device. It lives in the piix3 and the piix3 has intimate knowledge of it. When model a20 line propagation, this is actually an important detail. > Speaking of which, presumably i8042 should be an IsaDevice, which inherits > (amongst other things) a bus: Backlink property. > > What happens when my device has multiple parts that need to be referred to by > other devices? An interrupt controller is the most obvious example, but > similar issues occur for any device that has multiple connections of the same > type. Am I expected to create a whole bunch of dummy devices and a private > interface to bounce everything back to the main device, somethig like: > > Type: MagicInterruptController > Is-a: SystemBusDevice > Implements: MagicInterruptInterface > Properties: > in_pin0: Composition > in_pin1: Composition > out_pin: link No, there would be a single 'Pin' class that would be used for irqs. There is no need to subclass it. > > Type: MagicInterruptPin > Implements: IRQ > Properties: > pin_number: int > controller: BackLink > > It seems like rather than having a device implement a set of interfaces, it > might be better to have these be properties. Call them a Target<>. The above > then becomes something like: > > Type: MagicInterruptController > Is-a: SystemBusDevice > Properties: > in_pin0: Target > in_pin1: Target > out_pin: Link So this is more like how it works today except s/Link/child/ and s/Target/link/g. Regards, Anthony Liguori > > Where the Target<> properties are objects/methods provided by the device, and > the Link<> properties are pointed to them as the machine is constructed. > > Paul >