[lkml]   [2005]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: termios VMIN and VTIME behavior
    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.


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


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

    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:

    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

    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().


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

    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?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-23 05:35    [W:0.031 / U:7.316 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site