From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3vAg-00044c-Lr for qemu-devel@nongnu.org; Wed, 14 Sep 2011 15:30:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3vAe-0000wv-W6 for qemu-devel@nongnu.org; Wed, 14 Sep 2011 15:30:58 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:43097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3vAe-0000ua-Jt for qemu-devel@nongnu.org; Wed, 14 Sep 2011 15:30:56 -0400 Message-ID: <4E7100E9.70305@web.de> Date: Wed, 14 Sep 2011 21:30:49 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> In-Reply-To: <4E70EC90.8000904@us.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8FE2CA709B3C37C1807D74CC" Sender: jan.kiszka@web.de Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Edgar E. Iglesias" , Peter Maydell , Gerd Hoffmann , qemu-devel , Markus Armbruster This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FE2CA709B3C37C1807D74CC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-09-14 20:04, Anthony Liguori wrote: > Hi, >=20 > I spent a couple hours today writing up some comparisons and an initial= =20 > task list for converting qdev to QOM. The main location of this is the= =20 > wiki[1] but I thought I would inline it here for easier commenting. >=20 > I decided to do this because I wanted to avoid a massively long 00 patc= h=20 > explaining the rationale for the first batch of changes that I'm going = > to send out. >=20 > There is so much complexity in qdev and the device model in general tha= t=20 > it's hard to come up with a concise document. I'd really appreciate=20 > suggestions for topics to write up more rationale as that would help me= =20 > avoid writing a book on the topic :-) >=20 > [1] http://wiki.qemu.org/Features/QOM >=20 > =3D=3D Device Relationships =3D=3D >=20 > =3D=3D=3D Device Relationships in QDev =3D=3D=3D >=20 > The two main concepts in QDev are devices and busses. A device is=20 > represented > by a DeviceState and a bus is represented by a BusState. They do not=20 > share a > common base class. Devices can have properties but busses cannot. A d= evice > has no direct relationship with other devices. The only relationship i= s > indirect through busses. >=20 > 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= =20 > it via > a reference. All devices have a single parent bus and all busses have = a=20 > single > parent device. These relationships form a strict tree where every=20 > 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. >=20 > =3D=3D=3D Device Relationships in QOM =3D=3D=3D >=20 > Everything in QOM is a device. The concept of busses are implemented a= s an > interface that a device implements. Devices can have two types of=20 > relationships > with other devices: device composition or device backlinks.=20 "Backlink" somehow implies to me that there is also a forward link. Why "back"? >=20 > =3D=3D=3D Naming in QOM =3D=3D=3D >=20 > In QOM, there are only two namespaces, the device namespace and the pro= perty > namespace. >=20 > All devices have unique names. Globally unique? > There are no exceptions. Devices created > through composition are given unique names by deriving the name based o= n the > parent device name and a special separator, "::", that cannot be used i= n=20 > 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? 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... >=20 > Since a bus is-a device in QOM, there is no notion of having multiple b= usses > under the same device. A device can implement multiple bus interfaces,= =20 > but can > only be a single bus of any given bus interface. >=20 > Device names are completely independent of pathnames. For devices that= =20 > are no > user created, device names should be treated as opaque blobs with=20 > absolutely no > semantic meaning. >=20 > All device relationships are identified as named properties. A QOM pat= h=20 > 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=20 > or may > not refer to other devices. For instance, all of the following are=20 > valid paths: >=20 > /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-friend= ly. 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. So far for now. Jan --------------enig8FE2CA709B3C37C1807D74CC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5xAO0ACgkQitSsb3rl5xSB1gCfSbexPnKsBsuonQVgZeUy8RJy xsEAn3tbGQhAFixj1wiNE6Xbdr5VGyD6 =MKV/ -----END PGP SIGNATURE----- --------------enig8FE2CA709B3C37C1807D74CC--