Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs

[Paul Brook]

> 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