[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: