Messages in this thread | | | Date | Sun, 15 Dec 2013 12:24:13 +0100 | From | Gianluca Anzolin <> | Subject | Re: [REGRESSION] rfcomm (userland) broken by commit 29cd718b |
| |
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
| |