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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 4463 bytes --]

On 2011-09-14 20:04, 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. 

"Backlink" somehow implies to me that there is also a forward link. Why
"back"?

<snip>

> 
> === Naming in QOM ===
> 
> In QOM, there are only two namespaces, the device namespace and the property
> namespace.
> 
> All devices have unique names.

Globally unique?

>  There are no exceptions.  Devices created
> through composition are given unique names by deriving the name based on the
> parent device name and a special separator, "::", that cannot be used in 
> user
> supplied names.

That must be specified in more details. First of all, we likely need to
add a '::' prefix to reflect the root device so that no user can
override any auto-generated first-level device name.

What will be the unique name of some, say, smbus-eeprom?
::i440fx::PIIX4_PM::smbus-eeprom<something>? Will that something be
derived from its bus address? Or a counter that ran while all sibling
eeproms were created?

Such names can get fairly long I'm afraid...

> 
> Since a bus is-a device in QOM, there is no notion of having multiple busses
> under the same device.  A device can implement multiple bus interfaces, 
> but can
> only be a single bus of any given bus interface.
> 
> Device names are completely independent of pathnames.  For devices that 
> are no
> user created, device names should be treated as opaque blobs with 
> absolutely no
> semantic meaning.
> 
> All device relationships are identified as named properties.  A QOM path 
> name
> consists of a named device,

With a system root device called '/'. So '/' is another
character(-sequence) that is forbidden in device names.

> followed by a series of properties which may 
> or may
> not refer to other devices.  For instance, all of the following are 
> valid paths:
> 
>   /i440fx/piix3/i8042/aux
>   /i440fx/slot[1.0]/i8042/aux
>   /i440fx/slot[1.0]/bus/piix3/i8042/aux

Navigating along the properties sounds like a good idea. The properties
(hopefully) have telling names so that it is (generally) also user-friendly.

Nevertheless, I guess we should also establish and enforce some naming
rules for properties to avoid inconsistencies like "i2c" vs.
"my_i2c_devices" or just "d", ie. completely meaningless names. In the
end, variable (property) names now become part of the user interface.

This scheme also avoids having to merge the device namespace completely
into the path namespace, which would cause all kinds of conflicts again.

<snip>
So far for now.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]