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

[Paul Brook]

> >>> 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)?

> 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?

Paul