: Possibly, but the races still exist, and you can still get in a position : where the hardware is gone. (I've verified this, having done alot of : the work in the old pccard on suspend/resume.)

OK. So there is a small window there, but nothing that can be counted upon. One must therefore assume that the hardware is gone when the interrupt comes in...

: 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?

Yes. W/o explicit checks for 'am I gone' it is very hard, and where do you make them, and there is still a tiny race between the checking for am I gone and the touching of hardware. These races can be made so small as to be hard to lose.

That's one reason I think that having some way to terminate the current thread of execution at any instruction with a simple callback saying, "I killed your driver thread, cope with the loss of hardware" is about as good as we're going to get.

: When someone removes the bridge away from you while you're walking : across the chasm, how can you be expected to 'recover' from it? ;)

By hanging onto the bridge :-) Or registering a SIGBRIDGE handler and hoping that the 'chute deploys in time :-).