On Sun, Jun 13, 2010 at 4:34 PM, Paul Brook <p...@codesourcery.com> wrote: >> 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.
I agree this would be enough for the current RTC/APIC case. This doesn't help in EOI handling or message passing in any way, but we can make completely separate systems for those later when the need arises.