qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Blue Swirl
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Wed, 14 Sep 2011 20:37:56 +0000

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/qom

This set only contains the framework. Converting a few real life
devices would be helpful to see the framework in action.

Also, I didn't find anything about backlinks, did I miss something?

>>
>> 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
>
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]