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

[Anthony Liguori <anthony@codemonkey.ws>]

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