Consider the following situation. There is a driver talking to a device. An unmasked interrupt happens and the device is now gone. How does the driver know to stop what it is doing and respond to this disappearance in a sane way?

This sort of situation comes up in the pccard code. When someone ejects the card, an interrupt fires. If I were to remove the device from the tree in the interrupt handler, I can invalidate the softc that the driver is still using by freeing it. At that point the driver is running out of freed memory and all bets are off.

I can schedule a timeout to happen in 0 clock ticks so that it is then "safe" to remove the device, but the hardware is either gone or very close to being gone when the first interrupt happens, so we've moved the problem from memory corruption to a hardware hang.

It would be nice if there was some way to ref/unref the use of softc so I could remove the device right away, but defer the actual removal of the device and softc until the last deref of softc. This strikes me as a major PITA and may still result in a hardware hang.

It is my understanding that the pccard hardware still still exist for a period of time after the card is ejected (since it takes some period of time to move from the pins that caused the interrupt to the power/control/data pins being disabled). I don't know if this is true, or if true what the period of time is.

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...

Comments?