|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC] Plan for moving forward with QOM |
Date: | Wed, 14 Sep 2011 16:25:56 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 |
On 09/14/2011 03:37 PM, Blue Swirl wrote:
On Wed, Sep 14, 2011 at 8:22 PM, Anthony Liguori<address@hidden> 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:<address@hidden> Or http://repo.or.cz/w/qemu/aliguori.git/shortlog/refs/heads/qomThis 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<PlatformDevice2> 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 LiguoriCheers
[Prev in Thread] | Current Thread | [Next in Thread] |