On 8 June 2012 10:13, Paul Brook<address@hidden> 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 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.