Jason Thorpe wrote:

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

That was never my plan.  Besides, I have no control over when the softc is
deallocated.  It happens in config_detach() after the driver's detach routine
has finished (successfully).  So at this time there had better be no references
it.


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

It can't be done exactly like this for USB, because there is no interrupt
for disconnect.  There is an interrupt for status change, but to find out
what happened you need to talk to the hub that detected the change.
And this requires interrupts...
But I could still break it into two stages, but I'm not sure it would buy me
anything.

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

Not eventually, but right after device detach returns.  For some devices
I can imagine that it is quite hairy to to make sure there are no more refernces
to the softc.  Take a SCSI device, for example.  How do you know exactly what
the SCSI layer is up to when you're supposed to detach it?
But I note that the PCMCIA aic driver doesn't do detach. :-(
Not does the wdc driver.  Isn't this rather bad?

Question: Once vdevgone() has been called, is the device then "isolated"?
I.e. is it guaranteed that none of its methods (open, close, read, write, etc.)
will be called after this point?
Is it true for block devices as well?

> 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, as I said above it's not that easy.

    -- Lennart