From owner-freebsd-arch@FreeBSD.ORG Sat Jan 10 06:09:56 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CC2116A4CE; Sat, 10 Jan 2004 06:09:56 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BF4543D41; Sat, 10 Jan 2004 06:09:54 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id BAA10343; Sun, 11 Jan 2004 01:09:50 +1100 Date: Sun, 11 Jan 2004 01:09:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Scott Long In-Reply-To: <3FFEFA18.1060805@freebsd.org> Message-ID: <20040111005502.O22604@gamplex.bde.org> References: <3FFEFA18.1060805@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: Interrupt API change X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 14:09:56 -0000 On Fri, 9 Jan 2004, Scott Long wrote: > At the September DevSummit, Peter Wemm proposed changing the device > driver API so that interrupt routines return an INT instead of a VOID. This design error was rejected last time it was discussed (about 8-10 years ago). > The primary purpose of this is two-fold. The first is so interrupt > handlers can communicate back to the low-level interrupt routines > whether or not they were able to handle the interrupt. Heuristics > can then be built on this information to better detect things like > interrupt storms. That'a about all it can do. In the shared irq case, there is no alternative to calling all the handlers if one of the handlers did something, since activity by one handler is unrelated to activity by others (except as an optimization that only works in the edge triggered case -- devices usually rarely interrupt concurrently so assuming that thety never do is usually most efficient). In the non-shared case, individual handlers can better decide about interrupt storms in a device-specific way. The non-shared case will hopefully be almost all cases when APIC support becomes standard on i386's. > This change also paves the way for the proposal > to make interrupts be multi-tiered. That is another reason not to do it. Interrupts shouldn't be multi-tiered except in special cases. > The first level interrupt handler > can relay back whether it wants the second-level handler to be run > (similar to filter interrupt handlers in Max OS X). The first level interrupt handler should call (or schedule) other levels as necessary (as in RELENG_4, but not using inefficient scheduling as in -current). Bruce