On 2013-01-18, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
>
>> If not, is it a bug in the tty layer?
>
> Our tty layer has always done this.
We'll call it a feature, then.
I don't remember ever seeing it before. Either the test is different
(which might be), or the old non-helper tty driver would somehow cause
the open() to block/retry.
It looks like the old open() code checked to see if the port was
closing, waited for the close to finish, and then returned either
EAGAIN or ERESTARTSYS:
// If we are in the process of closing, wait for it to complete, then return
if (tty_hung_up_p(filp) || info->flags & ASYNC_CLOSING)
{
wait_event_interruptible(info->close_wait, !(info->flags & ASYNC_CLOSING));
return (info->flags & ASYNC_HUP_NOTIFY) ? -EAGAIN : -ERESTARTSYS;
}
I do think I recall seeing a user-space open() block for some time
under certain circumstances.
>> Does Posix say than an open() may fail if it's called while another
>> process is calling close()? IOW, is user-space code expected to retry
>> an open() call that returns EIO? [I've never seen user-space code
>> that did that...]
>
> Interesting question. I've never liked the fact we do it (its rude to
> the userspace) but it's not clear what the correct semantics are of
> an open as a port closes, given the close must complete first
> including any drains and control changes and the open may well not
> expect to block or hang for a long time.
If my driver now behaves the same as the "standard" driver where it
didn't used to, I'm going to claim it's an improvement.
--
Grant Edwards grant.b.edwards Yow! I'm sitting on my
at SPEED QUEEN ... To me,
gmail.com it's ENJOYABLE ... I'm WARM
... I'm VIBRATORY ...
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
