Xref: utzoo comp.dcom.modems:1276 comp.sys.att:2263 comp.unix.questions:5272
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!mandrill!neoucom!wtm
From: wtm@neoucom.UUCP (Bill Mayhew)
Newsgroups: comp.dcom.modems,comp.sys.att,comp.unix.questions
Subject: Re: GETTYDEFS, etc. (babbling getty)
Summary: Or did AT&T provide /dev/cuaN hooks?...
Message-ID: <978@neoucom.UUCP>
Date: 27 Jan 88 14:03:53 GMT
References: <142@mccc.UUCP+ <564@virginia.acc.virginia.edu+ <10321@mimsy.UUCP+ <39831@sun.uucp>
Organization: Northeastern Ohio Universities College of Medicine
Lines: 31

Hmmmm.  See below.  I was wondering about the warning in the
/usr/lib/uucp/L-devices file on the 3b1 Sys V, relase 3.51.  It
tells you to be careful not to have any dialer devices that have
names that begin with the letters "cua...".  I was wondering why; I
think I'm starting to get the picture now...  This bears further
investigation:
+
+  The "/dev/cuaN" lines are special in that they can be opened even when
+  there is no carrier on the line.  Once a "/dev/cuaN" line is opened,
+  the corresponding tty line can not be opened until the "/dev/cuaN"
+  line is closed.  Also, if the "/dev/ttydN" line has been opened
+  successfully (usually only when carrier is recognized on the modem)
+  the corresponding "/dev/cuaN" line can not be opened.  This allows a
+  modem to be attached to e.g. "/dev/ttyd0" (renamed from "/dev/ttya")
+  and used for dialin (by enabling the line for login in "/etc/ttytab")
+  and also used for dialout (by tip(1C) or uucp(1C)) as "/dev/cua0"
+  when no one is logged in on the line.
+ 
+ (The names are purely conventional; you can call the ports anything you wish,
+ and it won't affect the operation of this mechanism.)  When it says "the
+ corresponding tty line can not be opened until the '/dev/cuaN' line is closed",
+ it means that a blocking "open" on "/dev/ttydN" will block until 1) the
+ "/dev/cuaN" line is closed, which should cause DTR to drop with carrier
+ dropping shortly afterwards and 2) carrier comes back up after that.  The
+ "open" won't fail with an error; it will just wait until the dial-out program
+ is finished with the line and somebody dials in after that.
+ 
+ I presume other implementations of this work much the same way.


--Bill