RE: termios VMIN and VTIME behavior

[Mike Voytovich]

Please disregard - the user app was reading less than VMIN in the read()
call, so I suppose the current behavior in that case would be correct
(returning immediately with the number of bytes passed into read()
rather than waiting for VMIN or VTIME to be met before returning).

It doesn't appear that the behavior in this case is explicitly defined
by POSIX, but it seems like a reasonable thing to do.

thanks,
-mike

-----Original Message-----
From: Mike Voytovich 
Sent: Tuesday, November 22, 2005 6:18 PM
To: 'linux-kernel@xxxxxxxxxxxxxxx'
Subject: termios VMIN and VTIME behavior

Hi,

I have a question regarding the implementation of the termios VMIN and
VTIME.

For the case where VMIN>0, VTIME>0, Linux does not obey VMIN - when a
single character is received by the device, it is immediately returned,
instead of waiting for either the timer to expire or VMIN bytes.


In n_tty.c, if VTIME is set, tty->minimum_to_wake is always set to 1:

        if (!tty->icanon) {
                time = (HZ / 10) * TIME_CHAR(tty);
                minimum = MIN_CHAR(tty);
                if (minimum) {
                        if (time)
                                tty->minimum_to_wake = 1;
                        else if (!waitqueue_active(&tty->read_wait) ||
                                 (tty->minimum_to_wake > minimum))
                                tty->minimum_to_wake = minimum;


The POSIX spec describes different behavior:


[snip]
 11.1.7 Non-Canonical Mode Input Processing

In non-canonical mode input processing, input bytes are not assembled
into lines, and erase and kill processing shall not occur. The values of
the MIN and TIME members of the c_cc array are used to determine how to
process the bytes received. IEEE Std 1003.1-2001 does not specify
whether the setting of O_NONBLOCK takes precedence over MIN or TIME
settings. Therefore, if O_NONBLOCK is set, read() may return
immediately, regardless of the setting of MIN or TIME. Also, if no data
is available, read() may either return 0, or return -1 with errno set to
[EAGAIN].

MIN represents the minimum number of bytes that should be received when
the read() function returns successfully. TIME is a timer of 0.1 second
granularity that is used to time out bursty and short-term data
transmissions. If MIN is greater than {MAX_INPUT}, the response to the
request is undefined. The four possible values for MIN and TIME and
their interactions are described below.

Case A: MIN>0, TIME>0

In case A, TIME serves as an inter-byte timer which shall be activated
after the first byte is received. Since it is an inter-byte timer, it
shall be reset after a byte is received. The interaction between MIN and
TIME is as follows. As soon as one byte is received, the inter-byte
timer shall be started. If MIN bytes are received before the inter-byte
timer expires (remember that the timer is reset upon receipt of each
byte), the read shall be satisfied. If the timer expires before MIN
bytes are received, the characters received to that point shall be
returned to the user. Note that if TIME expires at least one byte shall
be returned because the timer would not have been enabled unless a byte
was received. In this case (MIN>0, TIME>0) the read shall block until
the MIN and TIME mechanisms are activated by the receipt of the first
byte, or a signal is received. If data is in the buffer at the time of
the read(), the result shall be as if data has been received immediately
after the read().

[snip]




Note that I did read a thread on LKML regarding termios behavior back
from 2002:

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0206.2/0355.html

However this seems to address the behavior of termios in general, rather
than this particular case of MIN>0, TIME>0.



Does anyone have an opinion regarding whether or not the Linux
implementation for this particular case (MIN>0, TIME>0) should be
changed to match POSIX?  Can I submit a patch?


thanks,
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/