From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KCyxg-0003HR-Hj for qemu-devel@nongnu.org; Sun, 29 Jun 2008 11:37:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KCyxc-0003Bt-4V for qemu-devel@nongnu.org; Sun, 29 Jun 2008 11:37:08 -0400 Received: from [199.232.76.173] (port=40326 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KCyxb-0003Bn-TT for qemu-devel@nongnu.org; Sun, 29 Jun 2008 11:37:03 -0400 Received: from il.qumranet.com ([212.179.150.194]:57771) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KCyxb-0005B2-GI for qemu-devel@nongnu.org; Sun, 29 Jun 2008 11:37:03 -0400 Date: Sun, 29 Jun 2008 18:37:02 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH 1/3] Change qemu_set_irq() to return status information. Message-ID: <20080629153702.GA12972@minantech.com> References: <20080629140120.5626.1590.stgit@gleb-debian.qumranet.com.qumranet.com> <486798A9.7060308@qumranet.com> <20080629141852.GD31298@minantech.com> <200806291553.55770.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806291553.55770.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On Sun, Jun 29, 2008 at 03:53:55PM +0100, Paul Brook wrote: > > >> The return value is less then zero if interrupt is masked, zero if it > > >> is known that interrupt is lost (due to coalescing) or greater then zero > > >> if interrupt is delivered or was successfully queued for delivery by > > >> interrupt controller. Device emulation can use this info as it pleases. > > >> Included patch adds detection of interrupt coalescing into PIC and APIC > > >> code for edge triggered interrupts. > > > > > > Instead of negative/positive/zero, consider returning an enum for > > > readability. > > > > I thought about that, but I sometimes do arithmetics on those values > > (when delivering interrupt to multiple CPUs), so result can be more then > > 1 sometimes. > > At minimum you need to document the meaning of these values. Especially as > you've now given two contradictory definitions - "greater than zero" isn't > something you can do arithmetic with. If you require -1/0/+1 then you have to > say that. In only place I do arithmetic on those values it is guarantied that the value is either zero (cpu lost interrupt) or one (cpu received interrupt), so the sum of those values make sense. If it greater then zero at least one processor will process an interrupt. I will document the return value in a comment in the next version of the patch. -- Gleb.