All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: mtk.manpages@gmail.com
Cc: linux kernel <linux-kernel@vger.kernel.org>,
	linux-serial <linux-serial@vger.kernel.org>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	Ivan <athlon_@mail.ru>
Subject: Re: man termios
Date: Fri, 21 Mar 2014 10:51:31 -0400	[thread overview]
Message-ID: <532C51F3.8030205@hurleysoftware.com> (raw)
In-Reply-To: <CAKgNAkhg4-QLwQaVxve6KXR=yy0XQik_4+iz5XytE1d_6NjQaw@mail.gmail.com>

On 03/21/2014 10:17 AM, Michael Kerrisk (man-pages) wrote:
> On Fri, Mar 21, 2014 at 3:03 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>> On 03/21/2014 09:15 AM, Michael Kerrisk (man-pages) wrote:
>>>
>>> On 03/21/2014 12:21 PM, Peter Hurley wrote:
>>>>
>>>> On 03/21/2014 06:45 AM, Michael Kerrisk (man-pages) wrote:
>>
>>
>>>>>> Finally, if the 'count' parameter is less than MIN, read() may return
>>>>>> before
>>>>>> MIN bytes have been received, if 'count' bytes have been received.
>>>>>
>>>>>
>>>>> Yes. But it's not clear to me here: do you mean that something in the
>>>>> man page (or in TLPI) needs fixing?
>>>>
>>>>
>>>> Well, what I mean here is that read() may also _not_ return until MIN
>>>> bytes have
>>>> been received, even if 'count' bytes have been received.
>>>
>>>
>>> Ahh -- I see what you mean. And, it looks like there is a point here where
>>> Linux
>>> differs from POSIX and (at least) Solaris. See the current man-page text
>>> below,
>>> in particular the MIN>0, TIME>0 case. I've also attached a simple test
>>> program
>>> that I used, below.
>>>
>>>          In noncanonical mode input is available immediately (without  the
>>>          user  having  to  type a line-delimiter character), no input pro‐
>>>          cessing is performed, and line editing is disabled.  The settings
>>>          of  MIN (c_cc[VMIN]) and TIME (c_cc[VTIME]) determine the circum‐
>>>          stances in which a read(2) completes;  there  are  four  distinct
>>>          cases:
>>>
>>>          MIN == 0; TIME == 0:
>>>                 If  data  is  available, read(2) returns immediately, with
>>>                 the lesser of the number of bytes available, or the number
>>>                 of  bytes  requested.   If  no  data is available, read(2)
>>>                 returns 0.
>>>
>>>          MIN > 0; TIME == 0:
>>>                 read(2) blocks until MIN bytes are available, and  returns
>>>                 up to the number of bytes requested.
>>>
>>>          MIN == 0; TIME > 0:
>>>                 TIME  specifies  the limit for a timer in tenths of a sec‐
>>>                 ond.   The  timer  is  started  when  read(2)  is  called.
>>>                 read(2)  returns  either when at least one byte of data is
>>>                 available, or  when  the  timer  expires.   If  the  timer
>>>                 expires  without  any  input  becoming  available, read(2)
>>>                 returns 0.  If data is already available at  the  time  of
>>>                 the call to read() the call behaves as though the data was
>>>                 received immediately after the call.
>>>
>>>          MIN > 0; TIME > 0:
>>>                 TIME specifies the limit for a timer in tenths of  a  sec‐
>>>                 ond.  Once an initial byte of input becomes available, the
>>>                 timer is restarted after each further  byte  is  received.
>>>                 read(2)  returns  when  any of the following conditions is
>>>                 met:
>>>
>>>                 *  MIN bytes have been received.
>>>
>>>                 *  The interbyte timer expires.
>>>
>>>                 *  The number of  bytes  requested  by  read(2)  has  been
>>>                    received.   (POSIX  does  not  specify this termination
>>>                    condition, and on  some  other  implementations  read()
>>>                    does not return in this case.)
>>>
>>>                 Because  the  timer is started only after the initial byte
>>>                 becomes available, at least one byte  will  be  read.   If
>>>                 data  is  already  available  at  the  time of the call to
>>>                 read() the call behaves as though the  data  was  received
>>>                 immediately after the call.
>>>
>>>          POSIX does not specify whether the setting of the O_NONBLOCK file
>>>          status flag takes precedence over the MIN and TIME settings.   If
>>>          O_NONBLOCK is set, a read() in noncanonical mode may return imme‐
>>>          diately, regardless of the setting of MIN or TIME.   Furthermore,
>>>          if  no  data is available, POSIX permits a read() in noncanonical
>>>          mode to return either 0, or -1 with errno set to EAGAIN.
>>
>>
>> All looks good.
>
> Peter, do you agree that Linux appears to differ from POSIX here? (Not
> sure if you tried my test program to verify...)

I did run the test program to validate that it's observed behavior is that
implemented by Linux, with which I'm very familiar.
I don't have a test setup for other *nixes.

I would be interested to know the results of

   ./noncanonical 0 5 3 0
   hello

and

   ./noncanonical 0 5 3 2
    hel

on other platforms.

With respect to POSIX compliance, it's hard to say. I'm not sure the
spec contemplates the degenerate case where max bytes < MIN. And specifically
with regard to terminal i/o behavior, POSIX is essentially ex post facto,
and is really documenting existing behavior.

Other than the degenerate case of max bytes < MIN, is there any other
variation between Solaris and Linux in non-canonical mode?

Regards,
Peter Hurley

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Peter Hurley <peter@hurleysoftware.com>
To: mtk.manpages@gmail.com
Cc: linux kernel <linux-kernel@vger.kernel.org>,
	linux-serial <linux-serial@vger.kernel.org>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	Ivan <athlon_@mail.ru>
Subject: Re: man termios
Date: Fri, 21 Mar 2014 10:51:31 -0400	[thread overview]
Message-ID: <532C51F3.8030205@hurleysoftware.com> (raw)
In-Reply-To: <CAKgNAkhg4-QLwQaVxve6KXR=yy0XQik_4+iz5XytE1d_6NjQaw@mail.gmail.com>

On 03/21/2014 10:17 AM, Michael Kerrisk (man-pages) wrote:
> On Fri, Mar 21, 2014 at 3:03 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>> On 03/21/2014 09:15 AM, Michael Kerrisk (man-pages) wrote:
>>>
>>> On 03/21/2014 12:21 PM, Peter Hurley wrote:
>>>>
>>>> On 03/21/2014 06:45 AM, Michael Kerrisk (man-pages) wrote:
>>
>>
>>>>>> Finally, if the 'count' parameter is less than MIN, read() may return
>>>>>> before
>>>>>> MIN bytes have been received, if 'count' bytes have been received.
>>>>>
>>>>>
>>>>> Yes. But it's not clear to me here: do you mean that something in the
>>>>> man page (or in TLPI) needs fixing?
>>>>
>>>>
>>>> Well, what I mean here is that read() may also _not_ return until MIN
>>>> bytes have
>>>> been received, even if 'count' bytes have been received.
>>>
>>>
>>> Ahh -- I see what you mean. And, it looks like there is a point here where
>>> Linux
>>> differs from POSIX and (at least) Solaris. See the current man-page text
>>> below,
>>> in particular the MIN>0, TIME>0 case. I've also attached a simple test
>>> program
>>> that I used, below.
>>>
>>>          In noncanonical mode input is available immediately (without  the
>>>          user  having  to  type a line-delimiter character), no input pro‐
>>>          cessing is performed, and line editing is disabled.  The settings
>>>          of  MIN (c_cc[VMIN]) and TIME (c_cc[VTIME]) determine the circum‐
>>>          stances in which a read(2) completes;  there  are  four  distinct
>>>          cases:
>>>
>>>          MIN == 0; TIME == 0:
>>>                 If  data  is  available, read(2) returns immediately, with
>>>                 the lesser of the number of bytes available, or the number
>>>                 of  bytes  requested.   If  no  data is available, read(2)
>>>                 returns 0.
>>>
>>>          MIN > 0; TIME == 0:
>>>                 read(2) blocks until MIN bytes are available, and  returns
>>>                 up to the number of bytes requested.
>>>
>>>          MIN == 0; TIME > 0:
>>>                 TIME  specifies  the limit for a timer in tenths of a sec‐
>>>                 ond.   The  timer  is  started  when  read(2)  is  called.
>>>                 read(2)  returns  either when at least one byte of data is
>>>                 available, or  when  the  timer  expires.   If  the  timer
>>>                 expires  without  any  input  becoming  available, read(2)
>>>                 returns 0.  If data is already available at  the  time  of
>>>                 the call to read() the call behaves as though the data was
>>>                 received immediately after the call.
>>>
>>>          MIN > 0; TIME > 0:
>>>                 TIME specifies the limit for a timer in tenths of  a  sec‐
>>>                 ond.  Once an initial byte of input becomes available, the
>>>                 timer is restarted after each further  byte  is  received.
>>>                 read(2)  returns  when  any of the following conditions is
>>>                 met:
>>>
>>>                 *  MIN bytes have been received.
>>>
>>>                 *  The interbyte timer expires.
>>>
>>>                 *  The number of  bytes  requested  by  read(2)  has  been
>>>                    received.   (POSIX  does  not  specify this termination
>>>                    condition, and on  some  other  implementations  read()
>>>                    does not return in this case.)
>>>
>>>                 Because  the  timer is started only after the initial byte
>>>                 becomes available, at least one byte  will  be  read.   If
>>>                 data  is  already  available  at  the  time of the call to
>>>                 read() the call behaves as though the  data  was  received
>>>                 immediately after the call.
>>>
>>>          POSIX does not specify whether the setting of the O_NONBLOCK file
>>>          status flag takes precedence over the MIN and TIME settings.   If
>>>          O_NONBLOCK is set, a read() in noncanonical mode may return imme‐
>>>          diately, regardless of the setting of MIN or TIME.   Furthermore,
>>>          if  no  data is available, POSIX permits a read() in noncanonical
>>>          mode to return either 0, or -1 with errno set to EAGAIN.
>>
>>
>> All looks good.
>
> Peter, do you agree that Linux appears to differ from POSIX here? (Not
> sure if you tried my test program to verify...)

I did run the test program to validate that it's observed behavior is that
implemented by Linux, with which I'm very familiar.
I don't have a test setup for other *nixes.

I would be interested to know the results of

   ./noncanonical 0 5 3 0
   hello

and

   ./noncanonical 0 5 3 2
    hel

on other platforms.

With respect to POSIX compliance, it's hard to say. I'm not sure the
spec contemplates the degenerate case where max bytes < MIN. And specifically
with regard to terminal i/o behavior, POSIX is essentially ex post facto,
and is really documenting existing behavior.

Other than the degenerate case of max bytes < MIN, is there any other
variation between Solaris and Linux in non-canonical mode?

Regards,
Peter Hurley


  reply	other threads:[~2014-03-21 14:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-20 18:42 man termios Peter Hurley
2014-03-21 10:45 ` Michael Kerrisk (man-pages)
2014-03-21 10:45   ` Michael Kerrisk (man-pages)
2014-03-21 11:21   ` Peter Hurley
2014-03-21 11:21     ` Peter Hurley
2014-03-21 13:15     ` Michael Kerrisk (man-pages)
2014-03-21 14:03       ` Peter Hurley
2014-03-21 14:03         ` Peter Hurley
2014-03-21 14:17         ` Michael Kerrisk (man-pages)
2014-03-21 14:17           ` Michael Kerrisk (man-pages)
2014-03-21 14:51           ` Peter Hurley [this message]
2014-03-21 14:51             ` Peter Hurley
2014-03-21 15:41             ` Michael Kerrisk (man-pages)
2014-03-21 16:11               ` Peter Hurley
2014-03-21 18:45                 ` Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=532C51F3.8030205@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=athlon_@mail.ru \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.