> On Sat, Jun 12, 2010 at 12:21 PM, Paul Brook <p...@codesourcery.com> wrote: > >> This patch allows to optionally attach a message to an IRQ event. The > >> message can contain a payload reference and a callback that the IRQ > >> handler may invoke to report the delivery result. The former can be used > >> to model message signaling interrupts, the latter to cleanly implement > >> IRQ de-coalescing logics. > > > > I don't like this. qemu_irq is a level triggered interface. Redundant > > calls to qemu_set_irq should (in principle) be a no-op. If you want > > message passing then IMO you should be using something else. > > Keeping the optional message and qemu_irq together means that we can > reuse the existing IRQ subsystem. I'd guess something more separated > would need duplicate allocation and delivery support and maybe even > SysBus etc. would need lots of work to support a new class of IRQs.
How do you propose message passing is handled when you have nested multi-layer interrupt trees? How long is the message data valid for? Who owns it? How is a receiver meant to know for format of the message being delivered, and who it's intended for? IMO message triggered systems are fundamentally different to level states. qemu_irq represents a level state, and I'd really like for it to stay that way. If we need/want a generic message passing interface, then that's a different problem, and needs to be done in such a way that the devices always agree on the type of message being passed. TBH I preferred the original system whereby the source can query the state of the sink (i.e "are you ignoring this line?"). Note that conceptually this should be *querying* state, not responding to an event. Paul