Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path

[Avi Kivity]

On 09/05/2011 12:02 PM, Peter Maydell wrote:
> >  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?)
>
> There are often significant constraints (eg "can only query at a clock
> edge", or "not guaranteed to be valid until some other signal has been
> high for at least this time"), which often means hardware will latch
> the input value internally. Obviously QEMU doesn't have to care about
> things to that level of detail. The reason we don't care is that we're
> really restricting ourselves to providing a programmer-visible approximation
> to the device behaviour. So I think the right question to ask about qemu_irq
> semantics is not "does this act like hardware?" but "what is the right
> interface between two components to let us conveniently implement the
> behaviour we need?"

Agree.

> This probably means that sometimes we want a line
> with state-querying and sometimes not.

Right, and either can be implemented in terms of the other.  The 
question is which requires less boilerplate.

> Ideally our device/object model ought to (a) let us model either option
> easily (b) let us easily upgrade a "no state querying" line to a "state
> querying" line by having the latter's interface be a superset of the
> former's.
>
> [IMHO the most important reason not to call it a qemu_irq is that
> 'irq' is a description of what the signal is used for, not of its
> behaviour. 'gpio' is a bit more neutral.]

Or 'line'.

--
error compiling committee.c: too many arguments to function