Re: [Qemu-devel] [RFC] Plan for moving forward with QOM

[Paolo Bonzini <pbonzini@redhat.com>]

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<PCIConnector> 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