Joe Emenaker wrote:
> Why, after years and years of needing them, are the /dev/cua's suddenly,
> seemingly, obsolete?
Rather than just saying RTFM, I've gathered it up for you.
=====================================================================
This is explained in the mgetty file: /usr/doc/mgetty/ttyS-cua.txt
QUOTE:
Date: Mon, 13 May 1996 07:57:09 +1000
From: Tony Nugent <[EMAIL PROTECTED]>
Can someone kindly explain the difference between the /dev/cua? and
/dev/ttyS? devices?
/dev/ttySxx devices are fully POSIX-compliant TTY devices. If you are
only going to be using one set of tty devices, you should be using
/dev/ttySxx.
/dev/cuaXX devices are different from /dev/ttySXX in two ways --- first
of all, they will allow you to open the device even if CLOCAL is not set
and the O_NONBLOCK flag was not given to the open device. This allows
programs that don't use the POSIX-mondated interface for opening
/dev/ttySxx devices to be able to use /dev/cuaXX to make outgoing phone
calls on their modem (cu stands for "callout", and is taken from SunOS).
The second way in which /dev/cuaXX differs from /dev/ttySXX is that if
they are used, they will trigger a simplistic kernel-based locking
scheme: If /dev/ttySXX is opened by one or more processes, then an
attempt to open /dev/cuaXX will return EAGAIN. If /dev/cuaXX is opened
by one or more processes, then an attempt to open /dev/ttySXX will
result the open blocking until /dev/cuaXX is closed, and the carrier
detect line goes high.
While this will allow for simple lockouts between a user using a modem
for callout and a getty listening on the line for logins, it doesn't
work if you need to arbitrate between multiple programs wanting to do
dialout --- for example, users wanting to do dialout and UUCP.
I originally implemented the cuaXX/ttySXX lockout mechanism back before
FSSTND established a standard convention for the use of tty lock files.
Now that it's there, people should use the tty lock files and not try
using /dev/cuaXX. The only reason why /dev/cuaXX hasn't disappeared yet
is for backwards compatibility reasons.
=====================================================================
And here's a quote from the Info file: /usr/info/mgetty.info-3.gz
QUOTE:
*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). If *all*
programs agree on using `/dev/cua*' only, it will work, too - but they
have to agree on one variant.
For some background about `ttyS' vs. `cua', you might want to read a
mail from the author of the Linux serial drivers, Ted Ts'o, posted to
the Linux-PPP mailing list. I have included it in `doc/ttyS-cua.txt'.
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),
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
money for useless calls to a hung machine.
I'd recommend against using `/dev/modem' as a link to the real
device, but if you do that, make it a *hard link* to the appropriate
`/dev/ttyS*'. A soft link will cause problems with the device ownership
because of a peculiarity in the linux `chown()' implementation (that I
refuse to work around).
=========================================================================
And, here's a quickie from the mgetty FAQ: /usr/doc/mgetty/FAQ.gz
Q: I have a Linux system, and while trying to dial out on /dev/cua1
(mgetty is running on /dev/ttyS1), it says "device busy" (EBUSY)???
A: use the same device (always!!) for dial-in and dial-out.
On Linux, use /dev/ttySx, on SunOS and *BSD use /dev/cuax.
--
...RickM...
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
