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: Fri, 16 Sep 2011 21:17:54 -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/16/2011 07:48 PM, Edgar E. Iglesias wrote:
On Fri, Sep 16, 2011 at 07:47:57PM +0300, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 03:50:28PM -0500, Anthony Liguori wrote:
On 09/15/2011 03:29 PM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 12:51:23PM -0500, Anthony Liguori wrote:
On 09/15/2011 11:59 AM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 11:33:00AM -0500, Anthony Liguori wrote:
On 09/15/2011 10:38 AM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 10:28:52AM -0500, Anthony Liguori wrote:
On 09/15/2011 09:25 AM, Gleb Natapov wrote:

There is no canonical parent link.  A device may have multiple (more
or less equivalent) parents.

What should be treated as the "canonical" link depends on what
you're trying to do.  In the case of OF, you want to treat the bus
as a parent.  If a device happens to sit on multiple buses, I'm not
really sure what you do.

Yes, "canonical" is a link to a bus. Can you give an example of a device
that sits on multiple buses?

Not all devices buses that they sit on.

Missing "have"? If device has no bus how do you talk to it? Who carries
the signal from a cpu to a device?

A good example is our favorite one to debate--the PIIX3.  Devices
PIIX3 is a collection of devices, not a device.

like the UART don't sit on a bus.  They don't have any links at all.
In PC UART sits on isa bus. How device can have no links at all? It just
glued to a motherboard not touching any wires?

A bus implies a bidirectional relationship.  IOW, the device has to
know that it sits on a ISA bus to be an ISA device.

And ISA device with UART on it definitely knows that.

IMO, this discussion is going nowhere, Partly because assummptions are
beeing made about how hardware "works".

Hardware works the way it gets designed, and it can be desinged in pretty
much anyway you want.

When it comes to devives, you can design them in a way so they become very
dependent on a specific bus. But you can also design them in a more genric
way so that they become bus agnostic. Then you just need to connect a bus
adaptor that hooks things up to the particular bus the device needs to be
hooked up to.

Sometimes, the bus adaptor becomes more like like wrapper that is part
of the logic, other times, the bus adaptor is just a passthru unit.

QEMU should allow us to model devices in a a bus agnostic way.

And this is the problem to fix in qdev. We need to kill buses in qdev. The approach really boils down to:

1) Add unique names to devices (this is needed because buses must have names because they must be addressable).

2) Eliminate any device that has two bus instances in it. I'm pretty sure IDE is the only example of this.

3) Move all BusState functionality to DeviceState and eliminate buses. This is a compatibility breaker but a critical change.

Along the way, we also need to refactor properties to support getters/setters and add composition properties and link properties. At some point, we need to introduce the QOM type system to get the full benefits of all of this but that can probably be mechanical once we've completed the above.

I think this is all well within the scope of 1.1 and can be done without a tremendous amount of churn in the tree.

Regards,

Anthony Liguori



reply via email to

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