From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Utb-0005tR-6w for qemu-devel@nongnu.org; Mon, 05 Sep 2011 04:51:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0UtZ-0004wz-Uc for qemu-devel@nongnu.org; Mon, 05 Sep 2011 04:51:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0UtZ-0004wc-Jy for qemu-devel@nongnu.org; Mon, 05 Sep 2011 04:51:09 -0400 Message-ID: <4E648D75.3000303@redhat.com> Date: Mon, 05 Sep 2011 11:51:01 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E58FC3F.6080809@web.de> <4E5BE7C5.60705@us.ibm.com> <4E5BFF51.9010503@web.de> <4E5C00F0.9070103@redhat.com> <4E5DF096.6070207@redhat.com> <4E6285BB.2010505@codemonkey.ws> <20110905083857.GB26890@edde.se.axis.com> In-Reply-To: <20110905083857.GB26890@edde.se.axis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" Cc: Lucas Meneghel Rodrigues , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Gerd Hoffmann 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