Date: Tue, 26 Oct 1999 01:03:45 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com Cc: imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910260103.SAA21028@usr06.primenet.com> In-Reply-To: <199910251827.MAA14189@mt.sri.com> from "Nate Williams" at Oct 25, 99 12:27:30 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910260103.SAA21028>