From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3wy2-0003NI-Ei for qemu-devel@nongnu.org; Wed, 14 Sep 2011 17:26:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3wy1-0003Ru-Ad for qemu-devel@nongnu.org; Wed, 14 Sep 2011 17:26:02 -0400 Received: from mail-gw0-f46.google.com ([74.125.83.46]:56480) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3wy1-0003Rp-6j for qemu-devel@nongnu.org; Wed, 14 Sep 2011 17:26:01 -0400 Received: by gwb15 with SMTP id 15so2552318gwb.33 for ; Wed, 14 Sep 2011 14:26:00 -0700 (PDT) Message-ID: <4E711BE4.6060708@codemonkey.ws> Date: Wed, 14 Sep 2011 16:25:56 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <20110914200009.GB17136@zapo> <4E710D05.6030008@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: Blue Swirl Cc: Peter Maydell , Anthony Liguori , Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" On 09/14/2011 03:37 PM, Blue Swirl wrote: > On Wed, Sep 14, 2011 at 8:22 PM, Anthony Liguori wrote: >> On 09/14/2011 03:00 PM, Edgar E. Iglesias wrote: >>> >>> On Wed, Sep 14, 2011 at 01:04:00PM -0500, 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 :-) >>> >>> Thanks Anthony, >>> >>> I'd appreciate if you could elaborate more on the backlinks. Also, >>> tiny code examples would help. Maybe you've got a git repo with >>> more code to link to? >> >> Message-Id:<1311558293-5855-1-git-send-email-aliguori@us.ibm.com> >> >> Or >> >> http://repo.or.cz/w/qemu/aliguori.git/shortlog/refs/heads/qom > > This set only contains the framework. Converting a few real life > devices would be helpful to see the framework in action. Unfortunately, I need to semantically change qdev first before I can convert real devices if the tree is going to keep working as expected. > > Also, I didn't find anything about backlinks, did I miss something? I had been using the term "socket" to describe [back]links and "plug" to describe composition types. Regards, Anthony Liguori > >>> >>> Regarding the composition, a problem I face (which I mostly just >>> hack my way around) is that inter device connections may exist >>> at various layers at the same time. For example, a device that is >>> burried under a couple of busses/bridges may somehow be tighly >>> connected to another device at a very different location in >>> the bus hierarchy by means of another overlayed interconnect (e.g >>> data channels, timing generation, IRQs etc). Maybe you could >>> clarify a bit more on how QOM handles these topics. >> >> Links are meant to handle this. You can have something like: >> >> + PlatformDevice1 >> + PlatformDevice2 >> + PciBus >> | >> +- PciDevice1 >> +- PciDevice2 >> | >> + I2CBus >> | >> +- I2CDevice1 >> |- pd2: link >> >> So you have I2CDevice that sites behind multiple levels of hierarchy, but >> has a direct relationship (via a link) to a platform device much higher in >> the hierarchy. This is an simple demonstration of how you can create a >> graph in QOM. >> >> qdev doesn't allow graphs in the object model which is the problem that >> you're having today. That's because its a tree with alternating levels. >> The top level is always a bus, the next level is always devices, the next >> level are always busses, etc. >> >> With QOM, there are only devices, and devices can link to 0 or more other >> devices. >> >> Regards, >> >> Anthony Liguori >> >> >>> >>> Cheers >> >> >> >