Xref: utzoo comp.dcom.modems:1244 comp.sys.att:2218 comp.unix.questions:5188
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!sri-unix!quintus!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.dcom.modems,comp.sys.att,comp.unix.questions
Subject: Re: GETTYDEFS, etc. (babbling getty)
Message-ID: <39831@sun.uucp>
Date: 25 Jan 88 03:13:00 GMT
References: <142@mccc.UUCP> <564@virginia.acc.virginia.edu> <10321@mimsy.UUCP> <148@mccc.UUCP>
Sender: news@sun.uucp
Lines: 68

> Well, we're using SysV R3.0, so apparently it is not trivial.  (Wonder
> what kind of kernel support is needed

The Sun version provides *two* "/dev" entries for each serial port; the minor
device number for the dial-out version is the minor device number for the
dial-in version plus 128 (i.e., the 8th bit is set).  Here is the description
from a manual page for the CPU serial ports:

	To allow a single tty line to be connected to a modem and used for
	both incoming and outgoing calls, a special feature, controlled by
	the minor device number, has been added.  Minor device numbers in
	the range 128 - 139 correspond to the same physical lines as those
	above (that is, the same line as the minor device number minus 128).

	A dial-in line has a minor device in the range 0 - 11 and is
	conventionally renamed "/dev/ttydN", where N is a number indicating
	which dial-in line it is (so that "/dev/ttyd0" is the first dial-in
	line), and the dial-out line corresponding to that dial-in line has
	a minor device number 128 greater than the minor device number of the
	dial-in line and is conventionally named "/dev/cuaN", where N is the
	number of the dial-in line.

	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.

It requires only minor changes to the device drivers, and adds only a
negligible amount of extra text and data to the kernel.  (And despite a claim
made in an earlier discussion of this feature, there is no problem whatsoever
making this work with streams.  Only one of the two devices can be open at a
time - no-delay opens of the dial-in device must fail if the dial-out device is
open - so there can't be two streams opened above the same device.)  It
requires *NO* changes to "getty", UUCP, "tip", "cu", etc.; it's all done
transparently by the driver.

> and why AT&T didn't provide it?)

Beats me.  It's certainly not hard to do, and it's not expensive in terms of
code or data space; it also means "uugetty", which is a MUCH clumsier way of
doing the same thing, could be deep-sixed (which would be a major maintenance
win, since they'd no longer have source to two almost-identical flavors of
"getty" to maintain, with fixes to one perhaps not getting propagated to the
other).

(And, before anybody asks, I have no idea whatsoever whether this will appear
in the merged Enhanced System V or not; it's done in the device driver, so it's
ultimately up to the hardware vendor to put it into their drivers.)
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com