From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0VGS-0006a2-Di for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:14:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0VGM-0001aF-MP for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:14:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0VGM-0001aA-E8 for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:14:42 -0400 Message-ID: <4E6492FB.9030306@redhat.com> Date: Mon, 05 Sep 2011 12:14:35 +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> <4E648D75.3000303@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: Peter Maydell Cc: Lucas Meneghel Rodrigues , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Gerd Hoffmann , "Edgar E. Iglesias" 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