| From | Sent On | Attachments |
|---|---|---|
| Warner Losh | Oct 23, 1999 11:08 pm | |
| Wes Peters | Oct 24, 1999 12:06 am | |
| Matthew Jacob | Oct 24, 1999 8:25 pm | |
| Nate Williams | Oct 25, 1999 9:46 am | |
| Warner Losh | Oct 25, 1999 11:22 am | |
| Nate Williams | Oct 25, 1999 11:27 am | |
| Warner Losh | Oct 25, 1999 11:40 am | |
| Warner Losh | Oct 25, 1999 11:50 am | |
| Matthew Jacob | Oct 25, 1999 11:52 am | |
| Nate Williams | Oct 25, 1999 11:57 am | |
| Nate Williams | Oct 25, 1999 12:02 pm | |
| Matthew Jacob | Oct 25, 1999 12:12 pm | |
| Nate Williams | Oct 25, 1999 12:14 pm | |
| Matthew Jacob | Oct 25, 1999 12:15 pm | |
| Nate Williams | Oct 25, 1999 12:20 pm | |
| Matthew Jacob | Oct 25, 1999 12:35 pm | |
| Warner Losh | Oct 25, 1999 12:46 pm | |
| Matthew Jacob | Oct 25, 1999 12:49 pm | |
| Terry Lambert | Oct 25, 1999 5:55 pm | |
| Terry Lambert | Oct 25, 1999 6:03 pm | |
| Nate Williams | Oct 25, 1999 6:04 pm | |
| Terry Lambert | Oct 25, 1999 6:09 pm | |
| Terry Lambert | Oct 25, 1999 6:12 pm | |
| Terry Lambert | Oct 25, 1999 7:20 pm | |
| Nate Williams | Oct 25, 1999 8:55 pm | |
| Wes Peters | Oct 25, 1999 9:54 pm | |
| Randell Jesup | Oct 26, 1999 4:13 am | |
| Nate Williams | Oct 26, 1999 8:24 am | |
| Randell Jesup | Oct 26, 1999 8:37 am | |
| Bill Fumerola | Oct 26, 1999 9:06 am | |
| Wes Peters | Oct 26, 1999 11:27 am | |
| Nate Williams | Oct 26, 1999 1:07 pm | |
| Wes Peters | Oct 26, 1999 1:08 pm | |
| Terry Lambert | Oct 26, 1999 6:40 pm | |
| Terry Lambert | Oct 26, 1999 6:48 pm | |
| Nate Williams | Oct 26, 1999 7:01 pm | |
| Nate Williams | Oct 26, 1999 7:03 pm | |
| Warner Losh | Oct 26, 1999 7:58 pm | |
| Christopher Masto | Oct 27, 1999 1:04 am | |
| Daniel O'Connor | Oct 27, 1999 1:11 am | |
| Warner Losh | Oct 27, 1999 9:27 am | |
| Nate Williams | Oct 27, 1999 10:03 am | |
| Warner Losh | Oct 27, 1999 10:11 am | |
| Wes Peters | Oct 27, 1999 10:16 am | |
| Nate Williams | Oct 27, 1999 10:17 am | |
| Warner Losh | Oct 27, 1999 10:20 am | |
| Nate Williams | Oct 27, 1999 10:32 am | |
| Warner Losh | Oct 27, 1999 10:39 am | |
| Wes Peters | Oct 27, 1999 10:48 am | |
| Christopher Masto | Oct 27, 1999 11:34 am | |
| Warner Losh | Oct 27, 1999 11:57 am | |
| Daniel O'Connor | Oct 27, 1999 5:33 pm | |
| Warner Losh | Oct 27, 1999 8:35 pm | |
| Daniel O'Connor | Oct 27, 1999 8:38 pm | |
| Wes Peters | Oct 28, 1999 1:23 pm | |
| Terry Lambert | Oct 29, 1999 9:56 am | |
| Nate Williams | Oct 29, 1999 11:51 am | |
| Terry Lambert | Oct 30, 1999 2:23 pm | |
| Terry Lambert | Oct 30, 1999 2:26 pm | |
| Nate Williams | Oct 30, 1999 3:09 pm | |
| Wes Peters | Oct 30, 1999 5:04 pm | |
| Warner Losh | Oct 30, 1999 10:31 pm | |
| Terry Lambert | Nov 1, 1999 12:11 pm | |
| Warner Losh | Nov 1, 1999 2:35 pm |
| Subject: | Re: Racing interrupts | |
|---|---|---|
| From: | Terry Lambert (tlam...@primenet.com) | |
| Date: | Oct 25, 1999 6:03:23 pm | |
| List: | org.freebsd.freebsd-arch | |
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 ter...@lambert.org
--- Any opinions in this posting are my own and not those of my present or previous employers.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message





