[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path
Date: Mon, 05 Sep 2011 11:51:01 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]