[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: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Wed, 14 Sep 2011 13:49:00 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 09/14/2011 01:04 PM, Anthony Liguori wrote:

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 

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.


Anthony Liguori

reply via email to

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