Re: Goals for 1.3?
bcwhite@verisim.com (Brian C. White) wrote on 04.01.97 in <[🔎] 32CEADE7.24CE7159@verisim.com>:
> > - For serial communication use ttyS* devices instead of cua* devices
>
> Could you give reasons for this, please.
This is from the mgetty docs:
-- snip --
*Important note:* Use the `/dev/ttyS*' devices for getty and for
dial-out (that is, for kermit, uucico, cu, seyon, ...) - *never* use
`/dev/cua*'. Dialing out on `/dev/cua*' will result in the error
message "device busy". (There are reasons why `mgetty' cannot use the
"`ttyS*' vs. `cua*' kernel locking mechanism", see below), and dialing
in (ugh) on `/dev/cua*' will result in dozens of strange things
happening because the process may not get a controlling tty.
Some guys seemingly can't resist posting misinformation to the net
all the time, don't believe 'em. The `/dev/cua*' devices are *not*
different from the `/dev/ttyS*' devices concerning data flow or modem
control lines. The only difference is how the device reacts if you do an
`open()': Opening `/dev/ttyS*' normally blocks until the "carrier
detect" line goes active (unless `open()' is called with the `O_NDELAY'
flag; `mgetty' and all dial-out programs do that), and opening
/dev/cua*' will return an error message (`errno=EBUSY') if another
process has the device already open, thus *preventing dial-out on
`/dev/cua*'* if `mgetty' is active on `/dev/ttyS*'.
We use `/dev/ttyS*' all the time for dial-in *and* for dial-out, and
believe me, it works, and it's the *only* combination that will work
properly. The kernel locking mechanism only works if you use modem
auto-answer (the getty process sleeps until the modem gets a carrier),
properly. The kernel locking mechanism only works if you use modem
auto-answer (the getty process sleeps until the modem gets a carrier),
and mgetty uses manual answer (it waits for the RING message from the
modem), which will save your callers a lot of grief because their calls
will only be answered if your computer is ready to receive a call. Part
of the motivation for writing mgetty was being tired of losing lots of
oney for useless calls to a hung machine.
-- snap --
Essentially, the cuaX devices are only good for the simple cases. Anything
more complicated breaks unless you use ttySX *and* a sensible locking
protocol, or it will break.
MfG Kai
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: