From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3vM5-0006RG-2a for qemu-devel@nongnu.org; Wed, 14 Sep 2011 15:42:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3vM3-00089k-DR for qemu-devel@nongnu.org; Wed, 14 Sep 2011 15:42:45 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:57710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3vM3-00088s-9k for qemu-devel@nongnu.org; Wed, 14 Sep 2011 15:42:43 -0400 Received: by yib2 with SMTP id 2so1987688yib.4 for ; Wed, 14 Sep 2011 12:42:42 -0700 (PDT) Message-ID: <4E7103AE.5060201@codemonkey.ws> Date: Wed, 14 Sep 2011 14:42:38 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <4E7100E9.70305@web.de> In-Reply-To: <4E7100E9.70305@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , "Edgar E. Iglesias" , Gerd Hoffmann , Markus Armbruster , Peter Maydell On 09/14/2011 02:30 PM, Jan Kiszka wrote: > 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"? Because I prefer to use confusing terminology :-) link is definitely better. I'll s/backlink/link/g >> >> === Naming in QOM === >> >> In QOM, there are only two namespaces, the device namespace and the property >> namespace. >> >> All devices have unique names. > > Globally unique? Yes. It's also unique for all backends too (or will be eventually). >> 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. Heh, I ended up doing this in my patch series as it turns out :-) > > What will be the unique name of some, say, smbus-eeprom? > ::i440fx::PIIX4_PM::smbus-eeprom? The PIIX4_PM appears as a function on the PIIX4 device. That means it will appear like: ::i440fx::piix4::pm::smbus-eeprom[N] > Will that something be > derived from its bus address? Or a counter that ran while all sibling > eeproms were created? It's derived during creation. > Such names can get fairly long I'm afraid... A user should never even see these names. A user probably will always interact with devices via paths. We can also look at doing things like user-defined aliases or something like that. >> 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. Yes, but there is no system root device. In normal scenarios, the main device would be something like the i440fx. That's a device that's explicitly created by the user. >> 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. Exactly. > 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. Indeed. > 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. Thanks for taking a look! Regards, Anthony Liguori > Jan >