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

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/14/2011 03:37 PM, Blue Swirl wrote:
> On Wed, Sep 14, 2011 at 8:22 PM, Anthony Liguori<aliguori@us.ibm.com>  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<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 Liguori
>>
>>
>>>
>>> Cheers
>>
>>
>>
>