From: "Stuart MacDonald" <stuartm@connecttech.com>
To: "David Dyck" <dcd@tc.fluke.com>,
"Alan Modra" <alan@linuxcare.com>,
"Kiyokazu SUTO" <suto@ks-and-ks.ne.jp>,
"Andrew Morton" <andrewm@uow.edu.au>,
"Arnaldo Carvalho de Melo" <acme@conectiva.com.br>,
"Kanoj Sarcar" <kanoj@sgi.com>,
"Christer Weinigel" <wingel@hog.ctrl-c.liu.se>,
"Robert Schwebel" <robert@schwebel.de>,
"Juergen Beisert" <jbeisert@eurodsn.de>,
"Theodore Ts'o" <tytso@mit.edu>,
"Sapan Bhatia" <sapan@corewars.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: changes between 2.2.20 and 2.4.x 'broke' select() from detecting input characters in my serial /dev/ttyS0 program
Date: Wed, 1 May 2002 11:03:57 -0400 [thread overview]
Message-ID: <00f501c1f121$6b7614c0$294b82ce@connecttech.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0204301451300.2964-100000@dd.tc.fluke.com>
From: "David Dyck" <dcd@tc.fluke.com>
> It turns out also that the O_WRONLY channel had CREAD turned off,
> which I would expect was appropriate for an output channel, and
> in 2.2 kernels, it didn't affect the O_RDONLY channel. If I enable
> the CREAD bit in termios c_cflag register for the O_WRONLY channel also
> then the select on the O_RDONLY channel reports characters available.
>
> I suspect that there is a different level of information sharing
> between the 2 channels that are open, but which is the correct behaviour,
> and why?
CREAD handling was changed to be correct; recently, but I don't know
exactly when. The 2.4 vs 2.2 difference sounds about right though.
Previously CREAD had been incorrectly handled by the driver and hadn't
been changed because some apps would break. Now data is correctly
ignored on receive when CREAD is off.
When you talk about the "O_WRONLY channel" and the "O_RDONLY channel"
you're not actually referring to separate things. Each serial port is
represented in the kernel as one entity that may be opened different
ways, possibly multiple times.
When you turn off CREAD in your write side, you turn off CREAD for the
whole port, including the read only side. This is not a bug in the
driver.
..Stu
next prev parent reply other threads:[~2002-05-01 15:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-01 0:28 changes between 2.2.20 and 2.4.x 'broke' select() from detecting input characters in my serial /dev/ttyS0 program David Dyck
2002-05-01 15:03 ` Stuart MacDonald [this message]
2002-05-01 16:45 ` David Dyck
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='00f501c1f121$6b7614c0$294b82ce@connecttech.com' \
--to=stuartm@connecttech.com \
--cc=acme@conectiva.com.br \
--cc=alan@linuxcare.com \
--cc=andrewm@uow.edu.au \
--cc=dcd@tc.fluke.com \
--cc=jbeisert@eurodsn.de \
--cc=kanoj@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robert@schwebel.de \
--cc=sapan@corewars.org \
--cc=suto@ks-and-ks.ne.jp \
--cc=tytso@mit.edu \
--cc=wingel@hog.ctrl-c.liu.se \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox