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: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Wed, 14 Sep 2011 15:22:29 -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: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


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]