From owner-freebsd-arch@FreeBSD.ORG Tue Apr 29 17:45:13 2003 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 6E22A37B405; Tue, 29 Apr 2003 17:45:13 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id D734143FA3; Tue, 29 Apr 2003 17:45:05 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id RAA88556; Tue, 29 Apr 2003 17:38:09 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h3U0c82r073289; Tue, 29 Apr 2003 17:38:08 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3U0c8Hj073288; Tue, 29 Apr 2003 17:38:08 -0700 (PDT) From: Archie Cobbs Message-Id: <200304300038.h3U0c8Hj073288@arch20m.dellroad.org> In-Reply-To: <5AC4B3BA-7AA0-11D7-BD29-000393B2C586@hda.com> To: Peter Dufault Date: Tue, 29 Apr 2003 17:38:08 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: Poul-Henning Kamp cc: Archie Cobbs cc: freebsd-arch@freebsd.org Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr 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: Wed, 30 Apr 2003 00:45:14 -0000 Peter Dufault wrote: > The issue is promoting not thinking about what context you're working in. > It makes sense to have a clean API for kicking off a worker thread, but > "automagic" threads that kick in due to lack of thinking out how things > work aren't ready for prime time. > > To do what you're recommending, use a "Permit me to be naive" flag. > That puts the complexity in one place recognizing that it might not be > the best place. I agree with that... I'm really trying to make out a more abstract point which is that while in practice interrupt events are "different" from other events that a driver sees because they're more time critical, in the more general view they are just events, just like any other event such as "transmit this packet" or "change media mode" or whatever. The fact that the device originates some event instead of the system/user means that an interrupt is the only mechanism available to deliver the event to the device driver (which can be thought of as a FSM). That doesn't necessarily imply that the event itself is somehow fundamentally different from system- or user-originated events. But the fact that "interrupt handlers can't sleep" means that the device driver writer has to treat them differently. This is of course standard practice and I'm not really arguing we should change it, I'm just pointing out that it's one of those "it's always been that way" things that perhaps causes more pain than necessary, and if looked at from first principles might ultimately not be seen as the most elegant way to do things. It evolved the way it is today not because of elegance, but because device driver writers must follow the kernel device API and kernel writers found it easier prohibit sleeping during interrupts :-) -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com