Re: ttydev_cdevsw has no d_purge

Hi Kostik,

2012/8/1 Konstantin Belousov <kostikbel_at_gmail.com>:
> I would blame tty subsystem rather then USB subsystem.  The d_purge
> method of the ttydev_cdevsw is not implemented, but it is the only
> measure that can break the deadlocks like the one I described. The
> d_purge shall wake up threads sleeping inside devsw methods, which was
> specifically added to notify driver about device gone events.

I guess d_purge was added quite recently, right?

In the current design, the USB code must call into tty_gone() to
report that the TTY is no longer associated with an actual device.
This shall result in all threads blocking on a TTY to be woken up.
Also, it will prevent any further calls into the USB code by the TTY
layer.

Still, if the processes are not actually interacting with the TTY
(e.g. sleep 100000, just waiting for nanosleep() to return), then
there is no way the TTY code can actually garbage collect the TTY. It
must stay there. Removing the actual TTY would introduce a whole bunch
of races and unwanted behaviour. Applications may cache the pathname
to the TTY. If the pathname were to be reused by another device, apps
would start writing to random TTYs. So that's why TTYs may still stick
around in devfs, even though the device underneath went missing. The
driver simply calls tty_gone() and leaves the TTY alone. It will die
eventually, but you shouldn't wait for it to happen.

Still, I seem to remember the USB code does something weird. I think
the USB serial driver tries to block until the TTY is actually
destroyed. This is a bug, which I've discussed with hselasky_at_ numerous
times. It simply must not do that.

-- 
Ed Schouten <ed_at_80386.nl>