[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 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
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, (continued)
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/14
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Jan Kiszka, 2011/09/14
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/14
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Jan Kiszka, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Jan Kiszka, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Kevin Wolf, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/16
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Edgar E. Iglesias, 2011/09/14
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM,
Anthony Liguori <=
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Gleb Natapov, 2011/09/15