On 09/14/2011 01:04 PM, Anthony Liguori wrote:
Hi,
I spent a couple hours today writing up some comparisons and an initial task
list for converting qdev to QOM. The main location of this is the wiki[1] but I
thought I would inline it here for easier commenting.
I decided to do this because I wanted to avoid a massively long 00 patch
explaining the rationale for the first batch of changes that I'm going to send
out.
There is so much complexity in qdev and the device model in general that it's
hard to come up with a concise document. I'd really appreciate suggestions for
topics to write up more rationale as that would help me avoid writing a book on
the topic :-)
[1] http://wiki.qemu.org/Features/QOM
== Device Relationships ==
=== Device Relationships in QDev ===
The two main concepts in QDev are devices and busses. A device is represented
by a DeviceState and a bus is represented by a BusState. They do not share a
common base class. Devices can have properties but busses cannot. A device
has no direct relationship with other devices. The only relationship is
indirect through busses.
A device may have zero or more busses associated with it via a has-a
relationship. Each child bus may have multiple devices associated with it via
a reference. All devices have a single parent bus and all busses have a single
parent device. These relationships form a strict tree where every alternating
level is a bus level followed by a device level. The root of the tree is the
main system bus often referred to as SysBus.
=== Device Relationships in QOM ===
Everything in QOM is a device. The concept of busses are implemented as an
interface that a device implements. Devices can have two types of relationships
with other devices: device composition or device backlinks. Device composition
involves one device directly creating another device. It will own life cycle
management for the created device and will generally propagate events to that
device (although there are exceptions).
Device backlinks allow one device to refer to another device in a looser
fashion. While there can be only one device composition relationship that
exists between two specific devices, a device can participate in an arbitrary
number of backlinks.
Device composition and backlinks are both strongly typed and can be typed as a
specific device type or as an interface. When typed as an interface, any
device that implements that interface can be used.
There is no explicit notion of parents in QOM. A typical bus relationship
would the bus having a backlink to the child device, and the child device having
a backlink to the bus.
Without device backlinks, device composition forms a multi-rooted strict tree.
With backlinks, the result are multiple directed graphs.
Peter often points out that he dislikes the directed nature of the graph links
in QOM. I assume he will again so I'll pre-emptively address it :-)
The reason they're directed is because that maps very well to C. Here's an
example of how these properties map to C:
struct I440FX {
Device parent;
PIIX3 piix3; // device composition
PciDevice *slots[32]; // device backlink
};
An embedded struct is device composition, a pointer to a struct is a backlink.
Since with device composition, you can only have a link between two nodes, you
could conceivably add a 'Device *parent' backlink to the Device class which
could get filled out for any instance of device composition. I dislike this
approach because there's not a whole lot of useful things you can do with a
Device and I suspect most people would upcast it to something else. I think
it's far better to have an explicitly typed backlink for those cases where
composition also involves a bidirectional relationship between devices.
In this specific example, the PIIX3 is-a PciDevice and all PciDevices have a
PciBus *bus backlink. That's whole the piix3 should talk to the PciBus IMHO as
opposed to relying on the composition link.
A bidirectional backlink is even harder to map to C. I'm not really sure how
you would do it. I'm not necessarily opposed to notion of having bidirectional
links by default but I just don't see a good mapping to something practical.
Regards,
Anthony Liguori
