Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Aug 2012 15:47:20 -0700
From:      Julian Elischer <julian@freebsd.org>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, Ed Schouten <ed@80386.nl>, freebsd-current@freebsd.org
Subject:   Re: ttydev_cdevsw has no d_purge
Message-ID:  <5019B1F8.5080802@freebsd.org>
In-Reply-To: <201208012341.25509.hselasky@c2i.net>
References:  <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <CAJOYFBDsK8cZYc28sKcC0qcZrpy2=A3QAHvP5fEj9gn=Acwciw@mail.gmail.com> <201208012341.25509.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 8/1/12 2:41 PM, Hans Petter Selasky wrote:
> On Wednesday 01 August 2012 22:46:58 Ed Schouten wrote:
>> Hi Kostik,
>>
>> 2012/8/1 Konstantin Belousov <kostikbel@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@ numerous
>> times. It simply must not do that.
> Hi Ed & Others,
>
> I think the problem is like this, that in order to re-use the unit numbers for
> USB serial tty devices, the USB stack needs to wait until a TTY is actually
> freed, right? Else you will have a panic on creating devfs entries having the
> same name.

I think that the /dev/entries can (and SHOULD) go away when the hardware
goes away and even be re-used.

The devfs entry is after all just a name..

it's the underlying parts (the bottom of the iceberg) that needs to 
stay to
handle calls from file descriptors that are still open and THAT
>
> For /dev/usb/XXX nodes the USB stack supports that the client and dynamic
> kernel USB device structures can be separated at any time. I think Andrew
> Thompson was part of that design, that we allocate a small structure
> containing some information that allows us to quickly _lookup_ the USB kernel
> device at every read/write/ioctl/whatever, and then we simply mark the so-
> called cdev_priv invalid in case of detach, and it is actually freed when the
> fd is closed, while the kernel structures go away immediately. I think this
> same approach must be taken inside the TTY layer. I'm not sure how easy this
> will be, though.
>
> --HPS
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5019B1F8.5080802>