[Top][All Lists]

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

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

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


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

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?




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.


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


Anthony Liguori


reply via email to

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