[OpenIndiana-discuss] stty source code

[James Carlson]

On 09/06/12 20:37, Reginald Beardsley wrote:
> The real issue is the pathologically complex handling of serial lines in Solaris and the ambiguous documentation.  I am not convinced that anyone, myself included, knows which direction is which.  I know which direction is in and out for communication w/ the local host, but that is all I'm sure of.  Coupled w/ the fact that no one seems to have done  much w/ a serial port connection in many years makes it more difficult.  

I disagree.  I've had some trouble with the USB drivers, to be sure, but
not with serial I/O in Solaris.

The driver naming scheme is fairly simple.  /dev/term/* are for inbound
connections, and their behavior is:

	- if DCD is not asserted, then open() blocks, and the tty is
	  not busy.

	- when DCD is asserted and no other process has the /dev/cua
	  node open, open() will unblock and the process has use of
	  the line.

	- if another process opens the /dev/cua/ node, then the open()
	  stays blocked (regardless of DCD) until the last close on
	  /dev/cua/ occurs.

The /dev/cua/* nodes are for outbound connections:

	- if some process has /dev/term/ opened with DCD asserted,
	  then you get EBUSY.

	- otherwise, open() connects to the serial port right away
	  and will either block (if DCD is down and it's a blocking
	  open), or will complete (if DCD is up or if it's a non-
	  blocking open).

	- if the open is blocked waiting for DCD to come up, it
	  will wake up when DCD is asserted.

Normal dial-out behavior is to do one non-blocking open of the
/dev/cua/* node, communicate with the modem (or TA or whatever is out
there), then open a second file descriptor on the same device in
blocking mode, which will sleep until DCD goes high.

As for the terminal modes, they're all explained in the termio(7I) man
page in excruciating detail.  However, they're frankly mostly obsolete,
except for SUS and POSIX conformance, and except for controlling the
low-level port configuration (bit rate, parity, hardware flow control,
and so on).  Normal applications that use serial ports immediately
disable opost and icanon and do their own processing on the raw bytes
because, frankly, who wants to have the driver corrupting the data?

If you believe that there's "ambiguity" in the documentation, then I
think it'd be a service to all users to point out the ambiguous points
and (if at all possible) suggest non-ambiguous replacements.

> I last used tip 14 years ago to connect to my ISDN router.  It took only a couple of minutes to setup.  The first forth MCU also took a couple of minutes to setup.  The second beat me senseless for 6 hours.
> 
> In light of the long history of misery and suffering by system admins at the hands of serial port connections, this should not be a big surprise. When I actually did a lot of RS-232 work I was running VMS 4.x on a MicroVAX  connecting to a variety of terminals and an 11/780 w/ an FPS-120B attached.  That was a long time ago when Sun was a young upstart I'd not even heard of.
> 
> I *may* build up OI from source so I can run under the debugger and resolve the issue.  But because I've modified the remote host to emit NL-CR, it's really not important to me other than it would be nice to have a reasonably behaved facility for connecting over a serial line to a remote host.  If I really get in a jam, I can run Linux. I just prefer not to if I can avoid it.  If I elect to work on the OI/Illumos serial port discipline, it will be for aesthetic  rather than practical reasons.

I argue that the problems occurred because you did not understand how
the components actually worked, and thus spent untold hours manipulating
the wrong bits.

I suggest getting a copy of C-Kermit rather than using tip.  tip doesn't
really do much in terms of terminal emulation -- it's truly ancient and
assumes that you have equivalent UNIX systems at both ends -- while
Kermit is highly configurable and has no such assumptions.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>