On Fri, Dec 13, 2013 at 12:35:26AM +0100, Alexander Holler wrote: > Am 12.12.2013 21:36, schrieb Peter Hurley: > > >> What currently happens is that when one kills rfcomm (and any other > >> terminal which might use that tty), the entry in /dev doesn't > >> disappear. That means the same call to refcomm with the same device > >> (e.g. [/dev/]rfcomm1 doesn't work. > > > > Thanks for the report, Alexander. > > > > Point 4 above details a different situation; something else is > > happening. > > > > Would you please detail the necessary steps to reproduce this regression? > > (How do you 'kill' rfcomm? etc. Shell command lines would be best.) > > Just call > > rfcomm connect rfcomm9 01:23:45:67:89:ab > > wait until the connection happened (a message will appear) and then > press ctrl-c. This still terminates the bluetooth connection, but the > device in /dev is now left. Yes I'm able to reproduce the regression which is indeed caused by that commit. However I'm puzzled. Surely there is a fifth case I didn't cover because when rfcomm_dev_state_change() is called, the tty_port is there but the tty is not, and therefore I cannot get a reference to it and send the HUP. I'll let you know when I have something working. > > Regards, > > Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
