[Top][All Lists]

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

Re: [Qemu-devel] [RFC] QOMification of AXI stream

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] QOMification of AXI stream
Date: Fri, 08 Jun 2012 22:17:44 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 06/08/2012 09:59 PM, Paul Brook wrote:
Of course we then hit the usual problem with QOM that we can only link
to objects, and it's impossible to expose multiple interfaces of the
same type.

I'm pretty sure Anthony claimed this was entirely possible --
presumably that's how Pins are going to work.

Really?  Every time I've talked to him I've got the opposite impression.
Part of the response has been that interrupt pins are the only case
where this actually occurs, so It's not worth fixing properly.

I think it depends on your definition of "properly".

There's really only three concepts in QOM that matter for this discussion:
1) objects 2) children and 3) links.

There is absolutely no difference between a Pin object and a SerialState
object. They both are first-class objects are far as QOM and concerned.
Both can have links to other objects.

The most common way for other objects to create objects is via children.  A
device could have a bunch of Pin child objects with that being the sole
communication mechanism with the outside world.

And those pin objects would presumably communicate back to the device via some
as-yet unimplemented PinMultiplex interface link?  Or are you expecting the
Pin objects to have an API call that allows the device to register an
arbitrary QEMUBH (or equivalent)?

Notifiers actually.  The rough model is Signal/Slots similar to GObject and/or 

A device could also have a 'PCISocket' child object (which inherits from
PCIDevice) in order to expose a PCI interface to the world.

For most bus-based devices, I think the above is poor design.  But that's
my opinion from a modeling PoV, QOM doesn't have an opinion from an
infrastructure PoV.

So what is a good design?  Are you hoping most of your interfaces are
stateless, so can be implemented directly on the device object?

QOM is not a panacea. We still need to have good objects/interfaces. For this specific example, it sounds like a job for the DMA API dwg/benh have proposed. I responded with more detail in another part of the thread.


Anthony Liguori


reply via email to

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