From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R45jM-0003aN-KM for qemu-devel@nongnu.org; Thu, 15 Sep 2011 02:47:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R45jL-0005GV-F8 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 02:47:28 -0400 Received: from mail-ww0-f53.google.com ([74.125.82.53]:37255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R45jL-0005GN-8G for qemu-devel@nongnu.org; Thu, 15 Sep 2011 02:47:27 -0400 Received: by wwg14 with SMTP id 14so2922590wwg.10 for ; Wed, 14 Sep 2011 23:47:26 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4E719F7C.10700@redhat.com> Date: Thu, 15 Sep 2011 08:47:24 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> In-Reply-To: <4E70EC90.8000904@us.ibm.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: Anthony Liguori Cc: Peter Maydell , Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" On 09/14/2011 08:04 PM, Anthony Liguori wrote: > The concept of busses are implemented as an > interface that a device implements. I noticed that you haven't written in the document how to make devices reside on a particular bus (PCI, ISA, I2C, ...). The three possibilities for this are: * a device implements an interface. I would rule this out because for most buses the devices will need to store some data (PCI: configuration data, pointer to the parent bus; ISA: pointer to the parent bus). Interfaces are implementation-only, so you have to place the data in each device and cause massive code duplication. * a device inherits from an abstract class, e.g. PCIDevice. It is useful to see how the inheritance tree would look like for two devices with a common chipset and multiple interfaces: Device NE2000 PCIDevice PCI_NE2000 ------> includes a NE2000 ISA_NE2000 ------> includes a NE2000 * a device is composed with a connector object. There is no PCIDevice class anymore, so the bus has an array of socket instead. The case above would look like this Device NE2000 (abstract) PCI_NE2000 ------> includes a PCIConnector ISA_NE2000 ------> includes an ISAConnector Or, if you insist on a closer mapping of real hardware, where there are no abstract classes, it would look like this: Device NE2000 PCI_NE2000 ------> includes an NE2000 and a PCIConnector ISA_NE2000 ------> includes an NE2000 and an ISAConnector Advantages of abstract classes are pretty obvious, so I will just list them: it is more similar to what is done in QDev, and perhaps it is more intuitive. Advantages of connectors include: * it is more flexible: it lets you choose between a more abstract and a more low-level representation (the two hierarchies above); * you have the option of showing a simpler device tree to the user, without the internal composition. This is important because, unlike QDev, composition in QOM is explicit. So QOM would place NIC properties in NE2000, not in *_NE2000 (right?). * related to this, it keeps property names more stable. If I understand correctly, if the device starts as ISA-only or PCI-only, i.e.: Device PCIDevice PCI_NE2000 and later you change it to support multiple buses, suddenly properties would have to be addressed differently to account for the composition of NE2000 inside PCI_NE2000. You could I guess implement "forwarder properties", but that would also lead to more boilerplate code. Any other opinions? Paolo