On 09/05/2011 11:38 AM, Edgar E. Iglesias wrote:
>
> We shouldn't really use the term IRQ as it's confusing. I like the term
> "pin" better because that describes what we're really talking about.
>
> qemu_irq is designed oddly today because is represents something that is
> intrinsically state (whether a pin is high or low) with an edge
> notification with the assumption that the state is held somewhere else
> (which is usually true).
I don't agree. That's not what qemu_irq represents.
It represents a wire, a mechanism to drive changes through logic paths
between state. It is intrinsically stateless.
It may be the case that it is missused in some places, or that it isn't
always the best thing to use to represent what ever you need to represent,
so that you want to complement with other mechanisms.
But universally replacing it with a stateful alternative seems wrong to me.
I agree that qemu_irq is inherently stateless. But I do think there
should be a way for the sink to query the line level. Whether it is
implemented as a cache of the last qemu_set() level, or with callbacks
that query the underlying state is not important, but we can't just rely
on edge triggers.
(real hardware can query a line at any time, yes?)
--
error compiling committee.c: too many arguments to function
