From owner-freebsd-arch Mon Oct 25 18: 4:35 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 8E0D614C04 for ; Mon, 25 Oct 1999 18:04:32 -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 DAA10258 for ; Tue, 26 Oct 1999 03:04:32 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA18004 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 03:04:32 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 80B28152E4 for ; Mon, 25 Oct 1999 18:03:58 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA29674; Mon, 25 Oct 1999 18:03:51 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAf8aW65; Mon Oct 25 18:03:43 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA21028; Mon, 25 Oct 1999 18:03:45 -0700 (MST) From: Terry Lambert Message-Id: <199910260103.SAA21028@usr06.primenet.com> Subject: Re: Racing interrupts To: nate@mt.sri.com Date: Tue, 26 Oct 1999 01:03:45 +0000 (GMT) Cc: imp@village.org, arch@freebsd.org In-Reply-To: <199910251827.MAA14189@mt.sri.com> from "Nate Williams" at Oct 25, 99 12:27:30 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 > > This is one reason that I want each driver in its own thread and that > > the interrupt that says the card is gone to effectively do a longjump > > to a "You are now gone, don't touch hardware, but cleanup the best you > > can" routine. However, I'm not sure what this would do to driver > > complexity. > > According to Sean Fagan, Stratus did in fact go to these kinds of > lengths to make suspend/resume*insert/eject work, but it required > re-writing/re-coding all of the drivers to support. > > It's certainly not impossible, but it does make the drivers that much > more complex. And, (not to disagree with Sean), I don't see how you > fix all the problems, simply because at some point you must assume the > hardware exists, and if it disappears in the middle of an operation > without any way of knowing that it's gone, how can you recover from it? > > When someone removes the bridge away from you while you're walking > across the chasm, how can you be expected to 'recover' from it? ;) In a puff of greasy orange smoke, you appear at the side of the chasm you just left before the bridge went away. 8-). I really, really don't think there are that many drivers, especially for PCCARD/PCMCIA attached devices, that keep a whole heck of a lot of state, and so I think the impact on the drivers would be rather small, actually. For drivers that have a lot of state -- well, what the heck do they need all that state for, it makes things difficult for kernel/driver CPU rentrancy! Even so, I think a 32 bit value capable of tracking the state transitions, and checkpointing of dangling pointers into volatile variables before they are made to dangle, should be enough. Really the only state that you need to recover is state in objects that are owned by the system (e.g. mbuf's, etc.) that you need to recover for a "nice" shutdown. In many cases, you could intentionally "leak", as an intentional strategy, until the drivers are brought up to spec. (I dislike this, since it seems rather "Windowsy", but it would work as a short term bridge solution). 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