> 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.
People are still pushing qemu_irq as an message passing interface, so I'm going to expand a bit more on how I think this could be avoided. Start with the assumption that qemu irq represents a single bit of information. The current implementation is stateless, but in principle it could remember its state and ignore redundant calls to qemu_set_irq. In order to workaround the periodic timer issue, we need some way of for the source device to interrogate the target device state relating to this link. The suggestions so far are along the lines of "what happened when I made this change". This makes me unhappy, because it's overlaying event semantics on top of a state based system. Instead I suggest that we should be describing what the target state associated with this input is. Suitable return values could be: * normal: This input effects the state of the target device. Note that this need not imply that changing the input actually effects the output at this time. e.g. if an interrupt controller is already processing a higher priority input, the low priority inputs should still return "normal" - the input will be processed once the unrelated high priority input is finished. * latched: This input has already effected target device state, and will be ignored until reset by some external event. Typically means an interrupt controller latches its inputs, and this input has already been latched. * masked: This input is ignored. In practice these should give approximately the same information as event based delivered/coalesced/dropped responses. The difference is that they are consistent with the state based nature of qemu_irq. Paul
