[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: |
Edgar E. Iglesias |
Subject: |
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM |
Date: |
Wed, 14 Sep 2011 22:27:08 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, Sep 14, 2011 at 03:22:29PM -0500, Anthony Liguori 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
>
> >
> >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.
Great, thanks for clarifying!
Maybe you can copy+paste this into your book :p
Cheers
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, (continued)
- 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, Gleb Natapov, 2011/09/15