Very Computer

What exactly is the difference between /dev/ttyS<n> and /dev/cua<n>?
I.e. device majors 4 and 5.

In the course of reading c.o.l.* over the weeks I've seen people
having problems with a tty advised to try using the cua instead, as well as
the converse, and "see if that fixes it".  :-)

Since I am frequently plugging one serial thing into another, I'd like
to operate from a position of knowledge rather than trial and error -
so can anyone provide a thorough and correct description of the
difference between these two devices?

--
  _                              

 \_/ \_________________________________________   206-743-6982, 742-8604 (fax)
 / \_/                                            7107 179th St SW
 \_/   Quality Software and Hardware Consulting   Edmonds, WA 98026, USA

The ttyS devices - when not opened O_NONBLOCKing - block your open(2)
syscall until at least the carrier detect signal is high. If the
corresponding cua device is busy, open(2) blocks, too.

The cua devices dont't care about carriers and open(2) non blocking.
If the corresponding ttyS device is in use, opening a cua device will
return EBUSY immediately.

For further information i advise you to view
/usr/src/linux/kernel/chr_drv/serial.c. Search for rs_open() and friends.
block_til_ready() is the one that makes the difference.
--

                        LunetIX Softfair
Lichtenrader Str. 41      12049 Berlin            Tel.: +49 30 6227300

      "... on LINUX use the ttyS-devices not the cua-devices. No, I'm not
       willing to disuss this here ..."

   Just great! The whole thing did not work with ttyS-devices at all --
   but is working just fine with a cua-device now ... bewildering!

      "Undocumented software is shitware!"

   The point is that the manual section 4 (devices) is nearly empty. It
   seems that people who write device drivers think, that they did a
   great job, when their driver is doing fine just FOR THEM and some
   others who could follow the development -- others are kept standing
   in the rain!

   Listen all you guys out there, who provide us with software of any
   kind for LINUX: We (the community) can't read your brains. So you got
   to write it down, what you indented with your code, its implemetation
   and the way it is to be integrated.

   If there is anything wrong with LINUX, it is its documentation.
      - where are the man-pages fd(4), hd(4), sd(4), rmt(4) etc.?
      - where is explained that LINUX does not know 'raw'-disks and why?
        (a.s.o, a.s.o)

   Not a single piece of everything that can be found in /dev is
   documented in any way. In this respect LINUX can drive you mad
   sometimes. No I'm not asking to make LINUX foolproof.

     "One can't make things foolproof, since fools are so genious"
     (Murphy)

   I'm just asking for keeping me from asking stupid questions or
   digging for answers in HOWTOs and FAQs where the answer often
   cannot be found. What LINUX heavily need is a 'm'-set of disks,
   which keeps traditional man-pages for everything in the system.

Regards, Peter
--
####################===============================****************************
# H.P. Heidinger   # Call  : +49-201-287433 (data) *      ~~ HPHBBS  ~~       *
# Steeler Str. 121 #       : V22/32/42bis/FAX, 8N1 *    UseNet City-Router    *

       "... on LINUX use the ttyS-devices not the cua-devices. No, I'm not
         willing to disuss this here ..."

   Just great! The whole thing did not work with ttyS-devices at all -- but is
   working just fine with a cua-device now ... bewildering!

      "Undocumented software is shitware!"

   The point is that the manual section 4 (devices) is nearly empty. It seems
   that people who write device drivers think, that they did a great job, when
   their driver is doing fine just FOR THEM and some others who could follow the
   development -- others are kept standing in the rain!

   Listen all you guys out there, who provide us with software of any kind for
   LINUX: We (the community) can't read your brains. So you got to write it
   down, what you indented with your code, its implemetation and the way it is
   to be integrated.

   If there is anything wrong with LINUX, it is its documentation.
      - where are the man-pages fd(4), hd(4), sd(4), rmt(4) etc.?
      - where is explained that LINUX does not know 'raw'-disks and why?
        (a.s.o, a.s.o)

   Not a single piece of everything that can be found in /dev is documented in
   any way. In this respect LINUX can drive you mad sometimes. No I'm not asking
   to make LINUX foolproof.

        "One can't make things foolproof, since fools are so genious" (Murphy)

    I'm just asking for keeping me from asking stupid questions.

Regards, Peter

Seems that I have to explain it a bit now... - mgetty+sendfax allows
dial-out and dial-in on the same line, and manual answer of the phone. If
you use ttyS for mgetty and cua for sendfax, sendfax will fail with EBUSY.
If you use cua for mgetty, programs will mysteriously fail because there's
no controlling tty on /dev/cua devices.
If you use ttyS for both programs, it works.

Quote:>   Just great! The whole thing did not work with ttyS-devices at all -- but is
>   working just fine with a cua-device now ... bewildering!

And please cut the *about "flow control not working on /dev/ttyS". The
kernel doesn't differenciate *at all* between /dev/ttyS and /dev/cua
except when opening the device and assigning a controlling tty (or not
doing so). All flow control / data i/o stuff is completely independent of
that.

Oh... btw... if you cite from my documentation and tell later on that it's
*and what I write is wrong, why don't you tell *ME* what problems
you've got?

Quote:>      "Undocumented software is shitware!"
>   The point is that the manual section 4 (devices) is nearly empty. It seems
>   that people who write device drivers think, that they did a great job, when
>   their driver is doing fine just FOR THEM and some others who could follow the
>   development -- others are kept standing in the rain!

Quote:>   Listen all you guys out there, who provide us with software of any kind for
>   LINUX: We (the community) can't read your brains. So you got to write it
>   down, what you indented with your code, its implemetation and the way it is
>   to be integrated.

Quote:>   If there is anything wrong with LINUX, it is its documentation.
>      - where are the man-pages fd(4), hd(4), sd(4), rmt(4) etc.?
>      - where is explained that LINUX does not know 'raw'-disks and why?
>        (a.s.o, a.s.o)

Quote:>    I'm just asking for keeping me from asking stupid questions.

gert
--
I've got a signature breakdown! Anybody got a spare one?

: > This seems like an obvious question, but I don't find a definitive
: > description in any of the docs.
: >
: > What exactly is the difference between /dev/ttyS<n> and /dev/cua<n>?
: > I.e. device majors 4 and 5.
: >
: > In the course of reading c.o.l.* over the weeks I've seen people
: > having problems with a tty advised to try using the cua instead, as well as
: > the converse, and "see if that fixes it".  :-)
: >
: > Since I am frequently plugging one serial thing into another, I'd like
: > to operate from a position of knowledge rather than trial and error -
: > so can anyone provide a thorough and correct description of the
: > difference between these two devices?
: >
: > --
: >   _                              

: >  \_/ \_________________________________________   206-743-6982, 742-8604 (fax)
: >  / \_/                                            7107 179th St SW
: >  \_/   Quality Software and Hardware Consulting   Edmonds, WA 98026, USA

:    I just want to underpin this request. I asked the very question a
:    couple of times but noone could give a resonable answer about this
:    topic.  Instead I recently got a getty-implementation in my hands,
:    where was said:

:       "... on LINUX use the ttyS-devices not the cua-devices. No, I'm not
:        willing to disuss this here ..."

:    Just great! The whole thing did not work with ttyS-devices at all --
:    but is working just fine with a cua-device now ... bewildering!

:       "Undocumented software is shitware!"

:    The point is that the manual section 4 (devices) is nearly empty. It
:    seems that people who write device drivers think, that they did a
:    great job, when their driver is doing fine just FOR THEM and some
:    others who could follow the development -- others are kept standing
:    in the rain!

:    Listen all you guys out there, who provide us with software of any
:    kind for LINUX: We (the community) can't read your brains. So you got
:    to write it down, what you indented with your code, its implemetation
:    and the way it is to be integrated.

:    If there is anything wrong with LINUX, it is its documentation.
:       - where are the man-pages fd(4), hd(4), sd(4), rmt(4) etc.?
:       - where is explained that LINUX does not know 'raw'-disks and why?
:         (a.s.o, a.s.o)

:    Not a single piece of everything that can be found in /dev is
:    documented in any way. In this respect LINUX can drive you mad
:    sometimes. No I'm not asking to make LINUX foolproof.

:      "One can't make things foolproof, since fools are so genious"
:      (Murphy)

:    I'm just asking for keeping me from asking stupid questions or
:    digging for answers in HOWTOs and FAQs where the answer often
:    cannot be found. What LINUX heavily need is a 'm'-set of disks,
:    which keeps traditional man-pages for everything in the system.
:    

: Regards, Peter
: --
: ####################===============================****************************
: # H.P. Heidinger   # Call  : +49-201-287433 (data) *      ~~ HPHBBS  ~~       *
: # Steeler Str. 121 #       : V22/32/42bis/FAX, 8N1 *    UseNet City-Router    *

Perhaps this is an avenue you have already explored, but have you retrieved
the man pages from sunsite.unc.edu in /pub/Linux/docs/LDP ?  I have found
this and the LDP publications a very very good source of information and
IMHO, far better written than the documentation produced by some commercial
Unix vendors for their high priced and (again IMHO) less functional *nix
implementations.  But then, if one pays $5000.00 or more for a *nix system
then one also purchases the privilege to complain about the documentation?
I personally LIKE having the source to go to to find out what's really going
on and where I have misinterpreted something!

        To all the developers and LDPers goes my unending praise and
respect for their knowledge and efforts.  It is most appreciated.

        Sincerely,
        Mark
--

P.O.Box 747 Decatur GA US 30031-0747      ICBM: 33 45 N / 084 16 W
+1.404.371.0291                         Cruise: 33 45 30 N / 084 16 50 W
   "We may note that, for the purposes of these experiments, the symbol
                "=" has the meaning "may be confused with."  

The only thing I can suggest is that you keep clear of
undocumented sofware.  Lack of documentation is often an
indication of poorly conceived and executed work.  

The problem with lack of documentation for Linux in general (and
the serial driver in particular) is that the code is based on
documentation for BSD-ish systems (SunOS, SysVR4) or Posix.  This
documentation is readily available to the developers but can't be
released with the code since it is not in the public domain(?).

In any case... the following explanation is taken from the
README.linux file from mgetty_ps.  It should give you an idea of
how it's meant to work.  Also, if you have access to, for
example, SunOS documentation (man 4 zs) you'll find that other
cua devices work in a similar way.

------------------------------------------------------------------------

1.  NEW SERIAL DRIVERS

    To many people's surprise (and a few people's disgust), the serial
    drivers have been upgraded.  The basic idea behind the new drivers
    is that callin and callout devices should not try to use the same
    line at the same time.  In the past, this was accomplished by jug-
     gling lockfiles.  The new scheme takes care of the problem in the
    kernel.  Instead of one modem device, there are now two: a callin
    device, named /dev/ttyS# (where # is the port number), and a call-
    out device, named /dev/cua# (again, # = port number).  The callin
    devices are used by programs like getty; the callout devices are
    used by programs like Seyon and Kermit.  If you don't have the
    callout devices in /dev, you create them with the mknod command.
    They are character devices, major number 5, minor number same as
    the corresponding callin device.

    So how does it work?  Simple...

    Suppose that kermit wants to open /dev/cua1 for a callout session.
    The kernel allows the line to be open if and only if no other
    program currently has the corresponding /dev/ttyS1 line open; if
    it does, the error EBUSY is returned in errno.  

    The /dev/ttyS1 line is a bit more complicated.  By default, the device
    'blocks' on open.  This means that the program will be stopped until
    the device is clear to open.  For the device to be clear, two things
    must be true:  no process can be using the corresponding /dev/cua1
    line, and the carrier detect line of the serial port must be high.
    While the device is blocking, it is not busy, so callout devices can
    use the line.  In other words, if getty is running on /dev/ttyS1, as
    long as no incoming calls open the line (causing the carrier to go
    high), other programs are free to use the line.  Blocking can be dis-
    abled by setting the O_NDELAY flag to the open system call.  In this
    case, carrier detect is not needed to open the line; however, if
    /dev/ttyS1 is busy, EBUSY is still returned in errno and the open fails.

    So... why didn't getty_ps work with this?  Getty_ps opened the line with
    the O_NDELAY flag set to do modem initialization and wait for RING to
    come over the line.  By doing this, the device is always busy, and any
    other program trying to use the line is not allowed.  This behaviour
    is the major change in the getty_ps package.

--

ttyS? block on an open call if carrier detect is low, meaning that the modem
is in an idle state and no one is attached.

cua? will not block and is the device to use when you wish to dial out, like
in UUCP using uucico, or kermit, or minicomm.

Does this answer your questions?

(and I think that this might be in the Serial FAQ [don't hold me to that])

--
Mike Horwath    IRC: Drechsau   BBS: Drechsau   LIFE: lover

Jacob's Ladder  612-588-0201  UUCP, UseNet, Linux files, BBS

[some good stuff deleted]

Quote:>Well, listen, guy: the linux developers do that *for free*. If you pay me,
>I'll write you every manpage that you want. If not, write it yourself.
>What, you don't know about anything about the Kernel? Then read the
>source.

Quote:>Ok, then take a weekend off, read all the kernel source, and stop whining
>that somebody else should ease your life instead of improving the linux
>sources. That's more important than documentation.

>gert

Steve
--
Steven M. Gallo                         "If you don't expect too much from
SUNY at Buffalo, Dept. of Comp. Sci.     me you might not be let down.."

Quote:>I think it highly offensive if somebody who get good stuff for free complains
>about those people doing the hard stuff not doing all the work for you.
>If these manpages ar lacking from your system, complain to the distributor
>or whoever gave you the system, but not to the people doing the work.
>Linux is something some people are doing for fun.

>    Helmut

Steve
--
Steven M. Gallo                         "If you don't expect too much from
SUNY at Buffalo, Dept. of Comp. Sci.     me you might not be let down.."

Second, some programs are written to code around the ttyS? block by
opening O_NBLOCK.  I believe from what I've read that the old getty
did this.  Therefore even somebody with the new terminal driver but
old serial line software may not be getting what you describe.

Moral: Anybody who is running into conflicts on the serial line ought
to be sure they have the latest versions of software.  Anybody who is
writing for the serial line ought to be sure they are using the new
driver as it's intended to be used.  No finger pointing, just a
reminder.

Regards, Ed

(Especially mgetty+sendfax can*not* use the ttyS/cua scheme because of
said restrictions)

gert
--
I've got a signature breakdown! Anybody got a spare one?

That's true for simple, stupid gettys. But it's plain false for
mgetty+sendfax.

For mgetty+sendfax, you have to use the *SAME* device for incoming and
outgoing calls. (mgetty will take care so that no collisions occur). Won't
work otherwise. Believe me. Or RTSL.

Anyway, the original poster asked for the difference between /dev/ttyS* and
/dev/cua* - and your answer described only the different use...

gert
--
I've got a signature breakdown! Anybody got a spare one?

When a process opens /dev/cuaN /dev/ttySN blocks, that is whatever is trying
to read from /dev/ttySN will not receive any chars.  This allows programs
like getty to listen on /dev/ttySN and not get confused when a comm program
opens /dev/cua1.

Also:

/dev/cuaN does not receive job control signals.  That is if you say:

/bin/sh </dev/cua1 >/dev/cua1

You will end up with a shell running on /dev/cua1, but it will ignore things
like ^C and ^Z that come through /dev/cua1.

Hope this helps,

Jim Nance