| 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: | Matthew Jacob (mja...@feral.com) | |
| Date: | Oct 24, 1999 8:25:51 pm | |
| List: | org.freebsd.freebsd-arch | |
What I really want is a kernel signal mechanism which will start a rundown of the driver thread which is not allowed to touch hardware, but can only free resources used by the driver. We have lots of tight loops in drivers in the kernel and it seems unwise to pessimize those so that this race can be dealt with...
Presumably the interrupt that notifies one that a card has been pulled is actually then managed by the bus device driver for that bus. This should ensure that the the bus nexus controlller is notified that the state of the hardware is changed.
This does nothing for threads that were active at the time of the interrupt. In this case, either the hardware is sane enough to continue to provide some rational non-faulting access (in the case of memory mapping), or you have to design a framework such that when the interrupt occurs, and the nexus driver now knows how to remap any memory mappings so that a safe non-faulting (if nonsensical) access can occur. Then some additional mechanism which notifies the actual node driver that things have changed will be invoked.
For systems I'm more familiar with, explicit obligate parent-child relationships have these specific notification mechanisms specified on a per parent-child type basis. It's hard to generalize such mechanisms into a usable general event notification mechanism because each bus has different possible async events. A PC cardbus has removal/insertion, a fibre channel arbitrated loop has LIP and then (re)arbitration for AL_PAs- who knows what Compact PCI provides?
What does newbus provide for this?
-matt
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message





