Oliver Neukum <oneukum@xxxxxxx> writes:
> On Monday 20 August 2012 11:32:48 Bjørn Mork wrote:
>> Hello,
>>
>> I just noticed that /dev/ttyUSBx devices are not destroyed and released
>> on USB device disconnect if some process keeps the file open, and
>
> Well, we have to return some error code. So the device cannot just go away.
I understand that. My concern is primarily that well behaved
applications should allow the device to go away by closing the file
handle on error. If they never see an error on hangup, then I do not
understand how this is supposed to work.
>> reading from the file does not return an error - it successfully reads 0
>> bytes instead.
>
> And indeed the hangup redirects the read method:
> static ssize_t hung_up_tty_read(struct file *file, char __user *buf,
> size_t count, loff_t *ppos)
> {
> return 0;
> }
That expains the observed behviour, yes. I have to ask: Why?
> If you got -EIO in older kernels, this point to the ordinary tty_read
>
> static ssize_t tty_read(struct file *file, char __user *buf, size_t count,
> loff_t *ppos)
> {
> int i;
> struct inode *inode = file->f_path.dentry->d_inode;
> struct tty_struct *tty = file_tty(file);
> struct tty_ldisc *ld;
>
> if (tty_paranoia_check(tty, inode, "tty_read"))
> return -EIO;
> if (!tty || (test_bit(TTY_IO_ERROR, &tty->flags)))
> return -EIO;
Yes, this is what I expected.
I'll try to find out exactly why this previously appeared to work.
>
>> This affects my gpsd usage, so I believe it must be a recent regression
>> or I would have noticed before.
>
> It would probably be best to bisect this.
Ouch, I was hoping to avoid that. Device disconnect will Ooops during
most of the window... And any workaround for that may affect the
result.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
