[Top][All Lists]
[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
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, (continued)
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Edgar E. Iglesias, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Gleb Natapov, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Gleb Natapov, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Edgar E. Iglesias, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Edgar E. Iglesias, 2011/09/16
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM,
Paolo Bonzini <=
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paolo Bonzini, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Peter Maydell, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paolo Bonzini, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Peter Maydell, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paolo Bonzini, 2011/09/15
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Avi Kivity, 2011/09/15
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15