bidirectional serial ports

[Steve Nuchia]

Recently I have found myself writing about the two-inode method
of handling bidirectional serial ports, which I believe is a
relatively recent innovation (3-4 years?), and didn't know who
should get the credit for it.  The method is outlined below.
I have used it in all my serial drivers since I encountered
in in Microport 286 Unix.  It is supported now in most 386s,
SunOS, and some others, but many boxes don't have it (A/UX
for one) and some of those who do don't document it well.

My question is, who thought it up?  Any historical notes appreciated,
but I don't think simple "sighting reports" should be posted.  Mail
me any from say '86 or earlier.

The method is to allocate one or more bits in the minor device
number for the serial ports to control some aspects of the line.
These aspects are often wired in as extensions to termio if not
as minor device bits.  As was the case with tape devices in the
early days, the problem with this is that not all the software
you want to use with a port knows about the extensions or has ways
to administer the settings.

It can be argued that certain serial port settings are logically
system configuration options rather than application options.
While this can be taken too far, it is often useful to think of
hardware handshaking configuration this way.  The system admin
sets up the /dev entry to have the right bits based on the
characteristics (and settings) of the attached peripheral, and
the application can and should ignore those aspects of the
connection.  I've used two mode bits, one to enable DCD/DTR
modem control and another to enable some form of hardware
flow control.  Exactly which form depends on the traditions
of the shop the driver is for (what we really need is a standard
for serial communications :-).

When modem control is used one arranges two names for each
physical port, analogous to the rmt0,nrmt0 stuff with tapes.
Some naming convention is necessary, take for instance
/dev/ttym0 for outdial and ttyM0 for indial.  The upper
case M would signify the "modem control" bit set.  The
driver enforces the following policies:

	At most one logical device may be open for any
	one physical port at a time.

	Attempts to open an outdial port currently open
	for indial will fail (EBUSY suggested)

	Attempts to open an indial port currently open
	for outdial will block in open.

	Attempts to open an indial port not currently open
	will block in open until DCD is asserted.  Blocked
	attempts will not prevent outdial opens.

	If DCD is lost while open for indial, take action
	as local policy or termio settings indicate --
	send SIGHUP, cause reads to return 0, whatever
	seems right.  There may be an exact answer to
	this but I haven't found it.

	DTR is asserted while the port is open and while
	any open attempt is blocked.  It is deasserted
	otherwise, and is deasserted for 1/2 second when
	the driver close routine is called.  This allows
	modems that support the feature to reset or at
	least hang up.

This combination of policies means that getty and uucico can
share a line with very little interference and no silly
uugetty games.  The only complications are a races involving
calls arriving while uucico has the line open but on hook and
the fact that uucico isn't prepared for EBUSY.  There is no
fix for the first problem, though having your Devices file
run in reverse order through your hunt group helps.  The
second problem causes uucico to give up if it tries a busy
line even though there may be lines available.  This is not
often noticed by sites with few lines.  The solution is to
have getty craft a lock file for the corresponding outdial
line when its open on the indial line returns, and to clear
the corresponding lock when it restarts.  Getting this right
is a little subtle, I've got code (nasty but working)
if anyone wants it.
-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
"Man is still the best computer that we can put aboard a spacecraft --
 and the only one that can be mass produced with unskilled labor."
					- Wernher von Braun