From owner-freebsd-arch@FreeBSD.ORG Fri Jan 9 11:28:49 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 9BA3616A4CE; Fri, 9 Jan 2004 11:28:49 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C0E443D2D; Fri, 9 Jan 2004 11:28:48 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i09JSliw015491; Fri, 9 Jan 2004 14:28:47 -0500 (EST) Date: Fri, 9 Jan 2004 14:28:47 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Scott Long In-Reply-To: <3FFEFA18.1060805@freebsd.org> Message-ID: 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: Fri, 09 Jan 2004 19:28:49 -0000 On Fri, 9 Jan 2004, Scott Long wrote: > All, > > At the September DevSummit, Peter Wemm proposed changing the device > driver API so that interrupt routines return an INT instead of a VOID. > 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. This change also paves the way for the proposal > to make interrupts be multi-tiered. 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). > > I'm not ready to go in the multi-level interrupt direction just yet, > but changing the API now will help that later if needed. The change > will consist of changing the driver_intr_t typedef in /sys/sys/bus.h > to return an int, and then doing a sweep of the entire tree. I expect > no functional change from this right now. Coming from a background in Solaris device drivers, I think is a good idea :) Can I suggest that instead of just returning 0 or non-zero, that you use something more indicative like INTR_CLAIMED / INTR_UNCLAIMED ?