On Sun, 27 Jun 1999 22:33:48 -0700 
 Lennart Augustsson <lennart@augustsson.net> wrote:

 > Imagine a device, e.g. a mouse, that has been opened for reading.  Now the device
 > is detached and its detach routine together with the general detach framework
 > will deallocate its softc and related data.

...the problem you're referring to is precisely why you don't want to
deallocate the softc when the removal interrupt happens :-)

The PCMCIA code does this in two steps:

	(1) Deactivation, at interrupt time, when the card is popped out
	    of the socket.  This is done with interrupts blocked.  E.g.
	    in the pcmcom driver, pcmcom_activate() is called with
	    DVACT_DEACTIVATE.  This routine steps through and calls
	    config_deactivate() for all of the com children, and
	    com_activate() does any front-end-specific disabling goo.
	    Basically, unhooks the interrupt handler, and disables
	    the pcmcia function.

	(2) Then the PCIC interrupt handler schedules the PCIC's thread
	    to call config_detach() with the child.  config_detach()
	    does a revoke of all open file descriptors for the device,
	    and then the softc gets freed eventually.

What you probably want to do here is mark the device as "dying",
and then defer the actul freeing of the softc until the last close
of the device, if you have things waiting.  Obviously, if things
are waiting, you'll know this, and can wake them up so they can
check the flag, and return EIO.

 > Well, what happens if the process that has it open is sleep()ing in read when this
 > happens?  First, nothing happens, but if this process then wakes up it will now try
 > and access data in a deallocated softc.  Not good.
 > 
 > Is the idea that the detach routine for a device should wake up any processes that
 > are still holding on to the device data?  And then make sure that they are finished
 > before finishing the detach.
 > If this is the case, will the general machinery guarantee that no new processes
 > enters the device driver while this is happening?
 > 
 >     -- Lennart
 > 
 > 

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>