From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaKHg-0000YN-0I for qemu-devel@nongnu.org; Mon, 12 Dec 2011 23:48:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaKHe-0006fF-K1 for qemu-devel@nongnu.org; Mon, 12 Dec 2011 23:48:07 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:42954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaKHe-0006c0-FU for qemu-devel@nongnu.org; Mon, 12 Dec 2011 23:48:06 -0500 From: Paul Brook Date: Tue, 13 Dec 2011 04:47:58 +0000 References: <4E70EC90.8000904@us.ibm.com> In-Reply-To: <4E70EC90.8000904@us.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112130447.58486.paul@codesourcery.com> Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Peter Maydell , Anthony Liguori , Jan Kiszka , Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" > 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. Is the type of piix3::bus a typo? I think this should be Backlink. What is the difference between "Is-a" and "Implements"? 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. I'm not so sure we should have Is-a at all. 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. 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. 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 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 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