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

[Anthony Liguori <aliguori@us.ibm.com>]

On 06/08/2012 09:13 PM, Paul Brook wrote:
>> On 8 June 2012 10:13, Paul Brook<paul@codesourcery.com>  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.

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.

> I disagree with this
> assesment.
>
> Given we do need to expose multiple instances of the same interface, I see a
> few different options:
>
> - Create a proxy object for each reciever which multiplexes onto a different
> interface on the main object.  For interrupt pins this basically means making
> the qemu_irq object part of the device tree, and have the actual device
> implement qemu_irq_handler (see hw/irq.h).  The equivalent of qemu_irq (i.e.
> irq.c/h) needs to be created for every duplicated interface.  It's worth
> noting that qemu_irq is about as simple as it gets, it's a single
> unidirectional call.
>
> - Make some form of handle an explicit part of the API.  IMO this is a really
> bad idea, and a step backwards.  In the qemu_irq case it means that the device
> raising the interrupt needs to know how the interrupt controller enumerates
> its input pins, and which one it's connected to.  Instead of making
> connections via a nice clean links we have a link and some other device
> specific information.  It's worse than the old callback+opaque pointer pair
> because user [machine description] has to provide that device specific
> additional value.
>
> - Link to properties, not objects.  This probably ends up similar to the first
> option, except with a framework and consistent implementation across different
> interfaces.

Let me read and respond to the rest of the thread.  I'm not sure a super 
abstract discussion here is going to be helpful

Regards,

Anthony Liguori

>
> Paul
>