qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Thu, 15 Sep 2011 08:47:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]