From owner-freebsd-arch Mon Oct 25 18:13:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2C2F814C04 for ; Mon, 25 Oct 1999 18:13:09 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA10330 for ; Tue, 26 Oct 1999 03:13:09 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA18088 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 03:13:08 +0200 (MET DST) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 6C2F514C04 for ; Mon, 25 Oct 1999 18:12:57 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id SAA28564; Mon, 25 Oct 1999 18:12:45 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAAxCaGV3; Mon Oct 25 18:12:37 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA21635; Mon, 25 Oct 1999 18:12:47 -0700 (MST) From: Terry Lambert Message-Id: <199910260112.SAA21635@usr06.primenet.com> Subject: Re: Racing interrupts To: imp@village.org (Warner Losh) Date: Tue, 26 Oct 1999 01:12:47 +0000 (GMT) Cc: nate@mt.sri.com, arch@freebsd.org In-Reply-To: <199910251850.MAA42106@harmony.village.org> from "Warner Losh" at Oct 25, 99 12:50:45 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Yes. W/o explicit checks for 'am I gone' it is very hard, and where > do you make them, and there is still a tiny race between the checking > for am I gone and the touching of hardware. These races can be made > so small as to be hard to lose. That's one reason I think that having > some way to terminate the current thread of execution at any > instruction with a simple callback saying, "I killed your driver > thread, cope with the loss of hardware" is about as good as we're > going to get. I know that we don't have kernel threads, let alone > driver threads so this isn't a viable option at this time, but > conceptually that's what you'll have to do, I think. This leaks, unless you track state, and if you track state, then you don't need to let the driver finish doing any diddling of the hardware, you can just arrest it at any time, with the only exception being an extra I/O bus "settle" cycle to protect yourself. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message