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