# pragma ident "@(#)bnu:PORTING	1.9 91/11/07 "
-earlw

-------------------------------------------
LATEST TESTING ON THE SERIAL PORTS (May 28)
-------------------------------------------
  For the following notes, it doesn't matter how you opened the tty
  (blocked, non-blocked, etc.).  The signals follow this convention:

    +5V to +15V is a SPACE, logic 0, On
    -5V to -15V is a MARK, logic 1, Off

  If UIOCDTRFLOW modem control flag is set, characters will be transmitted
  (written) until the CTS signal (HSKi) is pulled down to at least -5V (MARK).
  Once the CTS signal is pulled up above the -5V threshold, the transmission
  continues.  One thing to note is that grounding or floating the CTS signal
  is not going to stop transmission because neither is below the -5V needed.
  By using this mode, you will not get a SIGHUP signal or I/O error from the
  write() call because the only signal input pin (HSKi) is totally dedicated
  to sensing the swing in voltages of the CTS signal and none of these voltage
  swings are considered an "error".  No effect on reading.

  If UIOCMODEM modem control flag is set, characters will be transmitted
  (written) until the CTS signal (HSKi) is pulled down to at least -5V (MARK).
  At this time, an (EIO) I/O Error is returned from the write() call.  No
  SIGHUP signal is sent.  As a matter of fact, you can pull up or float the
  CTS signal and transmission will again continue.  Sometimes this doesn't
  work.  Flakly.  Your best bet is to catch the first I/O error. 
  If reading, you'll get an error 55 (Operation Would Block) if the CTS is
  pulled down.  Problem with this is that you won't know about this error
  for quite a while if the input buffer is full because if you're buffer
  had 100 bytes in it before the error occured, you would have to read all 100
  of these bytes (I think).

  If UIOCNOMODEM modem control flag is set, characters will be transmitted
  (written) without checking the CTS signal at all.  No effect on reading.

  Drat!  Checked with Rick, the IOP doesn't support the DCD pin so there's
  no way to even think of using the DCD stuff.  This is stupid.

Haven't tested the hardware flow control yet.  Need it for some modems.

Remember, all those files and directories that are created while under the
setuid programs will have the owner being tested and set to the Effective ID.

The ulockf.c code has to be changed to allow the flock() call instead of the
lockf().  Seems that locks() doesn't work on tty's.

Some functions return TRUE(1)/FALSE(0) while others return
SUCCESS(0)/FAIL(-1).  Want to guess how often this causes problems?

--------------------------
Getting TCP up and running
--------------------------

The HDB UUCP supports moving files across a TCP connection, but you'll need
to do a few things first:

  - Make sure the /etc/uucpd demon is in place (should be installed
    automatically when you install the BNU).

  - Update the /etc/services file with this line:
        uucp  540/tcp  uucp

  - Update the /etc/servers file with this line:
        uucp  tcp  /etc/uucpd

  - The 'Systems' file should have any entry such as this:
        macaux Any TCP uucp - ogin: macaux word: abcd

MESSAGES:

   "You are unknown to me"
	This means the machine you were trying to call doesn't have your
        machine name listed in their /usr/lib/uucp/Systems file.
	
The 'interface' within uucico is defaulted to "UNIX" unless overridden by the
'-i interface' option on the command line.

Available interfaces are:
	
  212
  801
  TCP
  UNIX

  Others that the code supports, but A/UX doesn't:

    Unetserver
    TLI
    TLIS
    DK
    Sytex

Protocols supported:

  G
  g
  e
  x	
  f
  t

  Others that the code supports, but A/UX doesn't:

    d

-- Structure of 'Systems' file:

    System_name Time    Type    Class    Phone    Login
    F_NAME      F_TIME  F_TYPE  F_CLASS  F_PHONE  F_LOGIN
    ------      ------  ------  -------  -------  -------
    cheddar     Any     ACU     1200     5551212  in: x word: y
    cheddar     Any     TCP     uucp     -
    cheddar     Any     TCP     port     23
    cheddar     Any     TCP     telnet   -        in: x word: y
    cheddar     Any     Direct  9600     -	  in: x word: y
    cheddar     Any     ACU     2400     5551212  in: x word: y

-- Structure of 'Devices' file:

    Type    Line    Line2      Class    Dialer-Token-Pairs
    D_TYPE  D_LINE  D_CALLDEV  D_CLASS  D_CALLER  D_ARG
    ------  ------  ---------  -------  --------  -----
    TCP     TCP     -          telnet   TCP       23
    Direct  tty0    -          Any      direct
    Direct  tty1    -          Any      direct
    ACU     tty0    -          Any      direct
    ACU     tty1    -          Any      direct
    ibx     tty0    -          1200     ibx-modem-1200 
    ibx     tty1    -          1200     ibx-modem-1200 

If the slave uucico says to "Restart", you can continue transfering files 
where you left off instead of starting sall over again.

PROBLEMS

Problems with the port or to put it another way "Some things A/UX 2.0.1
doesn't do that AT&T 5.4 does":

  -DFLOCK_OPTION
    The exiting code uses lockf() which can't lock a tty port, so we'll use
    lockf(0 instead.

  -DHUPCL_OPTION
    A/UX doesn't set the HUPCL flag when an initial open is made on a tty port.
    We'll set it when we open it.

  -DEXCLUSIVE_PORT_OPTION
    A/UX provides a flag, FLOCKOUT, that can be used to test if a file is
    already open.  We'll use it to abort a port open if it's already been
    opened.  This is much better than opening the port, then trying to
    lock it.  Less change of hanging (look at the kernel sccio.c)
 
  -DSTATFS_OPTION
    A/UX's ustat() call doesn't handle the huge number of inodes of UFS
    filesystems, but statfs() does.

General problems with the bnu:

  - Most commands don't complain when they have errors. From what I've seen
    so far, there's a lot of calls where no one bothers checking to see if
    the call has an error.  I thought 5.4 was supposed to be "commerical
    quality"?

  - The dependencies in the makefiles are a joke.  Because some source files
    actually include others -- it's a mess.

  - How about a uucp deamon that can tied many uucico's together across many
    systems to support a massive uucp operation using A/UX systems sharing
    a large uucp spool directory via NFS?

  - You can have locked-up tty ports if one process opens the port with no
    delay and another doesn't.

===============================================================================
A/UX 2.0.1 Serial Ports
===============================================================================

The Macintosh serial ports are DIN-8 sockets (8 pins) connected to a Zilog
SCC chip.  This ports are based on the RS-422 standard but may be wired in
the RS-423 standard to drive RS-232C devices.  A/UX being UNIX based, the
RS-232C standard is of more interest to us than the RS-422.  The standard
DIN-8 pinout on the Mac (looking at the end of the plug):

                       /-------\
                      /   2 1   \
                      | 5   4 3 |
                      \  8 7 6  /
                       ---------
		(flat-bottom part of plug)

  1   HSKo	Output Handshake
  2   HSKi	Input Handshake or external clock
  3   TxD-	Transmit Data -
  4   GND	Signal Ground
  5   RxD-	Receive Data -
  6   TxD+	Transmit Data +
  7   GPi	General-Purpose input	(A/UX doesn't use this)
  8   RxD+	Receive Data +

Believe it or not, A/UX's SCC driver examines only the 'CTS' (Clear To Send)
status register from the SCC chip and it ignores the 'DCD' (Data Carrier
Detect) SCC status register (at least I couldn't find any reference to it...).
What this all means is this:  A/UX expects the CTS and DCD signals from the
DIN-8 jack to be on pin 2.  Period.  Forget having separate CTS and DCD signals 
because it ain't possible dude.  So, you gotta make up your mind about which
signal you want to monitor because there's only one pin you can use.  The
only rational reason for this is that the original Macintoshes didn't have
the 'GPi' (pin 7) interface which would allow the SCC chip to monitor the DCD
on pin 7 and the CTS on pin 2.

Unlike some UNIX systems, A/UX will not drop the DTR (pin 1) unless you tell it
to.  A simple close will not do unless the HUPCL flag is set.  What this means
is that each program has to catch signals and drop the DTR themselves or it
will not get dropped and a modem might just "stay on the line" forever.  If you
expect to be killed via a 'kill -9', your only option is to use the HUPCL flag
because you can't catch this signal.

The CLOCAL flag is used only for the HSKi stuff and it doesn't appear to work
well anyway...

So, we should provide a way for the DTR to be dropped on a open of a tty port
to ensure the line is hungup before we move on.


The output voltages on the DIN-8 pins are right at the +-5VDC range which is
as close to the noise margin as you can get.  No wonder the signals are so
flakly....


===============================================================================

Typical Computer to Modem RS232-C 25-pin Cable Configuration

         Computer (DTE)                                   Modem (DCE)
  -----------------------------                  ----------------------------- 
  Frame Ground        (GND)   1 ----------------  1 Frame Ground        (GND)
  Transmit Data       (TD)    2 >>------------>>  2 Transmit Data       (TD)
  Receive Data        (RD)    3 <<------------<<  3 Receive Data        (RD)
  Request To Send     (RTS)   4 >>------------>>  5 Clear To Send       (CTS)
  Clear To Send       (CTS)   5 <<------------<<  4 Request To Send     (RTS)
  Data Set Ready      (DSR)   6 <<------------<<  6 Data Set Ready      (DSR)
  Signal Ground       (SGND)  7 ----------------  7 Signal Ground       (SGND)
  Data Carrier Detect (DCD)   8 <<------------<<  8 Data Carrier Detect (DCD)
  Data Terminal Ready (DTR)  20 >>------------>> 20 Data Terminal Ready (DTR)
  Ring Indicator      (RI)   22 <<------------<< 22 Ring Indicator      (RI)

===============================================================================

  

---------------------------------------------------
Macintosh DIN-8 to Macintosh DIN-8 cable connection
---------------------------------------------------

Do-it-yourself:

     DIN-8                                DIN-8
  ------------                         ------------
  HSKo (DTR) 1 >>------------------->> 2 (CTS) HSKi
  HSKi (CTS) 2 <<-------------------<< 1 (DTR) HSKo
  TxD- (TD)  3 >>------------------->> 5 (RD)  RxD-
  GND  (GND) 4 ----+-------------+---- 4 (GND) GND
  RxD- (RD)  5 <<--|-------------|--<< 3 (TD)  TxD-
  TxD+ (?)   6 n/c |             | n/c 6 (?)   TxD+
  GPi  (?)   7 n/c |             | n/c 7 (?)   GPi
  RxD+ (?)   8 <<--+             +-->> 8 (?)   RxD+

Apple cable (590-0340 / 590-0552):

     DIN-8                                DIN-8
  ------------                         ------------
  HSKo (DTR) 1 >>----- red --------->> 2 (CTS) HSKi
  HSKi (CTS) 2 <<----- brown -------<< 1 (DTR) HSKo
  TxD- (TD)  3 >>----- green ------->> 5 (RD)  RxD-
  GND  (GND) 4 ------- yellow -------- 4 (GND) GND
  RxD- (RD)  5 <<----- orange ------<< 3 (TD)  TxD-
  TxD+ (?)   6 >>----- silver ------>> 8 (?)   RxD+
  GPi  (?)   7 <<----- purple ------<< 7 (?)   GPi
  RxD+ (?)   8 <<----- blue --------<< 6 (?)   TxD+

Cable setup to use with the DIGILOG 620 (based on the Apple cable):

  == DTE Mac to Cable #1 ===        == Cable #2 to DCE Mac ===
     DIN-8            25-pin        25-pin           DIN-8
  ------------        ------        ------        ------------
  HSKo (DTR) 1 >>-->> 20 DTR >>-->>  5 CTS >>-->> 2 (CTS) HSKi
  HSKi (CTS) 2 <<--<<  5 CTS <<--<< 20 DTR <<--<< 1 (DTR) HSKo
  TxD- (TD)  3 >>-->>  2 TD  >>-->>  3 RD  >>-->> 5 (RD)  RxD-
  GND  (GND) 4 ------  7 GND ------  7 GND ------ 4 (GND) GND
  RxD- (RD)  5 <<--<<  3 RD  <<--<<  2 TD  <<--<< 3 (TD)  TxD-
  TxD+ (?)   6 >>-->> 21 SQ  >>-->> 22 RI  >>-->> 8 (?)   RxD+
  GPi  (?)   7 <<--<<  8 CD  <<--<<  8 CD  <<--<< 7 (?)   GPi
  RxD+ (?)   8 <<--<< 22 RI  <<--<< 23 ?   <<--<< 6 (?)   TxD+

---------------------------------------------
Modem Cable setup to use with the DIGILOG 620
(Based on the 590-0552 Apple cable)
---------------------------------------------

  Cable #1
  --------
  The DIN-8 plug goes to the A/UX system and the 25-pin plug goes
  to the DTE side on the DIALOG 620.

  A/UX		  Dialog (DTE)
  DIN-8           25-pin
  ------          -------
  HSKo 1 >>---->> 20 DTR
  HSKi 2 <<----<<  5 CTS
  TxD- 3 >>---->>  2 TD
  GND  4 --------  7 GND
  RxD- 5 <<----<<  3 RD
  TxD+ 6 >>---->> 21 SQ
  GPi  7 <<----<<  8 DCD
  RxD+ 8 <<----<< 22 RI

  Cable #2
  --------
  The DIN-8 plug goes to the modem and the 25-pin plug goes
  to the breakout box, then to the DCE side of the DIALOG 620.

  Modem	  	      Breakout Box              Dialog (DCE)
  DIN-8           25-pin        25-pin          DIN-8
  ------          --------------------          ------
  HSKo 1 >>---->> 20 DTR >>-->>  5 CTS >>---->>  5 CTS
  HSKi 2 <<----<<  5 CTS <<--<< 20 DTR <<----<< 20 DTR
  TxD- 3 >>---->>  2 TD  >>-->>  3 RD  >>---->>  3 RD
  GND  4 --------  7 GND ------  7 GND --------  7 GND
  RxD- 5 <<----<<  3 RD  <<--<<  2 TD  <<----<<  2 TD
  TxD+ 6 >>---->> 23 ?   >>-->> 22 ?   >>---->> 22 ?
  GPi  7 >>---->>  8 DCD >>-->>  8 DCD >>---->>  8 DCD
  RxD+ 8 <<----<< 22 RI  <<--<< 21 ?   <<----<< 21 ?

------------------------------------------------
Macintosh DIN-8 to Modem 25-pin cable connection
------------------------------------------------

Do-it-yourself:

     DIN-8                                25-pin
  ------------                         ------------
  HSKo (DTR) 1 >>------------------->> 20 DTR
  HSKi (CTS) 2 <<-------------------<<  8 CD
  TxD- (TD)  3 >>------------------->>  2 TD
  GND  (GND) 4 ----+------------------  7 S-GND
  RxD- (RD)  5 <<--|----------------<<  3 RD
  TxD+ (?)   6 n/c |
  GPi  (?)   7 n/c |
  RxD+ (?)   8 <<--+

Apple cable (590-0335 / 590-0556):

     DIN-8                                25-pin
  ------------                         ------------
  HSKo (DTR) 1 >>------------------->> 20 DTR
  HSKi (CTS) 2 <<---------------+---<<  6 DSR
                                +---<<  8 CD
  TxD- (TD)  3 >>------------------->>  2 TD
  GND  (GND) 4 ----+------------------  7 S-GND
  RxD- (RD)  5 <<--|----------------<<  3 RD
  TxD+ (?)   6 n/c |
  GPi  (?)   7 n/c |
  RxD+ (?)   8 <<--+

Unmarked Apple Telecom cables:

     DIN-8                                25-pin
  ------------                         ------------
  HSKo (DTR) 1 >>---------------+--->> 20 DTR
                                +--->>  4 RTS
  HSKi (CTS) 2 <<-------------------<<  6 DSR
  TxD- (TD)  3 >>------------------->>  2 TD
  GND  (GND) 4 ----+------------------  7 S-GND
  RxD- (RD)  5 <<--|----------------<<  3 RD
  TxD+ (?)   6 n/c |
  GPi  (CD)  7 <<--|----------------<<  8 CD
  RxD+ (?)   8 <<--+

Cable setup to use with the DIGILOG 620 (based on the Apple cable):

  == DTE Mac to Cable #1 ===        == Cable #? to DCE Modem ===
     DIN-8            25-pin        25-pin        25-pin
  ------------        ------        ------        ------
  HSKo (DTR) 1 >>-->> 20 DTR >>-->> 20 DTR >>-->> 20 DTR
  HSKi (CTS) 2 <<--<<  8 CD  <<--<<  8 CD  <<--<< 8  CD
  TxD- (TD)  3 >>-->>  2 TD  >>-->>  2 TD  >>-->> 2  TD
  GND  (GND) 4 ------  7 GND ---+--- 7 GND ------ 7  GND
  RxD- (RD)  5 <<--<<  3 RD  <<-|<<  3 RD  <<--<< 3  RD
  TxD+ (?)   6 >>-->> 21 SQ  n/c|
  GPi  (?)   7 <<--<<  8 CD  n/c|
  RxD+ (?)   8 <<--<< 22 RI  <<-+

The bnu programs cause DTR to drop by setting the speed to 0 for 2 seconds; this
works under A/UX 2.0.1

The A/UX serial ports are really screwed up.  DTR is high all the time except
when it feels like dropping for god-knows what reason.  Sometimes (random it
seems) a port will wait for carrier before completing the open but most of the
time you can even unplug the cable and the open completes.  If I tie 2 & 3
(DIN-8) together, at random times the DTR will drop and come up again. 

If you screw around with the ports enough, you can hang the whole A/UX system. 
 
You can get a port into a state where it's not possible to open the port unless
you reboot.

Because of the modem port problems, uucico will drop DTR of a port after every
session (master or slave).

'cu' already drops DTR before quiting.

BUGS:

  For some reason, on the A/UX to A/UX serial link, imsg reads a shitload
  of zeros....

  After using bnu, doing a 'uustat -p' shows this:
     LK.024.000.000: 12707
  Why is this lock file not cleared up?

===============================================================================
Program Logic
===============================================================================

Only three bnu programs actually deal with the issues of I/O control and they
are: ct, cu and uucico.  The dial() function also deals with I/O control
issues.  Our primary concern with A/UX tty I/O controls are dealing with the
Carrier Detect and Data Terminal Ready signals.  Can't do a lot about tty
throughput...

'ct' external uucp functions and variables:

    Dc		char []		name of the communications tty line
    Debug	int 		debugging level (0 - 9)
    Progname	char []		name of the program
    Verbose	int		verbose mode (0=off, 1=on)
    devreset(void)		resets 'Devices' and 'Dialers' files
    drop_DTR(int fd)		drops DTR for a few seconds
    fdig(char *string)		finds first digit in a string
    fn_cklock(char *name)	determine if the device name is locked
    getto(char *flds[])		connect to remote machine
    rddev(char *type, char *dev[], char *buf, int devcount) find and unpack a
				line from device file for this caller type.
    rmlock(char *name)		remove the named lock
    setservice(char *service)	init 'Systems', 'Devices', 'Dialers' lists as
				specified from 'Sysfiles'.
    sysaccess(init type)	check administrative files access

'cu' external uucp functions and variables:

    Debug	int 		debugging level (0 - 9)
    Dev_mode	mode_t		saved device mode (st_mode)
    Duplex	int		full(=YES) or half(=NO) duplex
    Euid	uid_t		effective user ID
    Evenflag	int		if set, use even parity
    Mytype	char *		requested line type (D_TYPE) used by rddev()
    Oddflag	int		if set, use odd parity
    Progname	char []		name of the program
    Terminal	int		if set, remote is a terminal
    Uerror	int		global error code
    UerrorText	char *[] 	global error code text
    Verbose	int		verbose mode (0=off, 1=on)
    altconn(struct call *call)	place a telephone call to system from cu when
				telephone number or direct line used.
    conn(char *system)		place a telephone call to system, login, etc.
    drop_DTR(int fd)		drops DTR for a few seconds
    fd_rmlock(int fd)		both BNU lock file and advisory locks removed
    (*genbrk)(int fd)		generate break
    line_8bit	int		if set, line is in 8 bit mode
    rmlock(char *name)		removed named lock
    setservice(char *service)	init 'Systems', 'Devices', 'Dialers' lists as
				specified from 'Sysfiles'.
    strsave(char *string)	allocate memory and copy string to it
    sysaccess(init type)	check administrative files access
    term_8bit	int		if set, terminal is in 8 bit mode

'uucico' depends of these other uucp externals:

    Ct_CHDIR		- variable
    Ct_OPEN		- variable
    Dc			char Dc[]	name of the communications tty line
    Debug		int 		debugging level
    Debug		- variable
    Dev_mode		- variable
    Env			- variable
    Euid		- variable
    Ifn			- variable
    JobGrade		- variable
    Logfile		- variable
    Loginuser		- variable
    Myname		- variable
    Mytype		- variable
    Nstat		- variable
    Ofn			- variable
    Pchar		- variable
    Progname		char []		name of the program
    RemSpool		- variable
    RemUlimit		- variable
    Restart		- variable
    Retrytime		- variable
    Rmtname		- variable
    Role		- variable
    Setup		- (*function)
    SizeCheck		- variable
    Spool		- variable
    Teardown		- (*function)
    Uerror		- variable
    UerrorText		- variable
    Uid			- variable
    Ulimit		- variable
    User		- variable
    Uucp		- variable
    Write		- (*function)
    Wrkdir		- function
    acConnected		- function
    acEnd		- function
    acInit		- function
    assert		- function
    callBack		- function
    callok		- function
    chremdir		- function
    cmtseq		- function
    cntrl		- function
    conn		- function
    countProcs		- function
    delock		- function
    eaccess		- function
    errent		- function
    findgrade		- function
    fixline		- function
    gename		- function
    gnxseq		- function
    guinfo		- function
    imsg		- function
    interface		- function
    logFind		- function
    logent		- function
    mchFind		- function
    mlock		- function
    msgtime		- variable
    myName		- function
    omsg		- function
    pfConnected		- function
    pfEndfile		- function
    pfInit		- function
    pfStrtConn		- function
    restline		- function
    rmlock		- function
    savline		- function
    scInit		- function
    scReqsys		- function
    scWrite		- function
    scanlimit		- function
    setservice		- function
    setuucp		- function
    startup		- function
    sysaccess		- function
    systat		- function
    ulkseq		- function
    versys		- function
    xuucico		- function
    xuuxqt		- function


FLOW:

  ct ------------------------->+
                               |
  cu ------>+---> altconn() -->+
            |                  |
            +---> conn() ----->+---> getto() ---> processdev()
                               |
  uucico -------> conn() ----->+
                               |
  dial.o -->+---> conn() ----->+
            |                  |
            +----------------->+

standard hangup style:

	set baud B0	hangup now.
	HUPCL		hangup on last close. default on open in 5.4

modem drop:  SIGHUP

setline() in line.c
sethup() in line.c
ttygenbrk() in line.c


BSD 4.3:
  TIOCSBRK	start break
  TIOCCBRK	clear break
  TIOCSDTR	start DTR (raise)
  TIOCCDTR	clear DTR (drop)
  TIOCHPCL	hangup on last close.

  When the CD drops a SIGHUP is sent.


MAKE SURE THAT WE SET THE HUPCL FLAG FOR ALL PROGRAMS THAT DEAL WITH SERIAL
PORTS BECAUSE A/UX DOESN'T DO THAT FOR US!

dropdtr() code is in place in line.c but it doesn't use the (*Ioctl()) form,
perhaps it should?
need to make sure sethup() is ok.

THEORY:

  savline()
	- saves fd 0 attributes
	- called by uucico in SLAVE mode
	- called by dial 

Wtch out for the vfork() trick...

-------------------------------------------------------------------------------
UUCP THEORY
-------------------------------------------------------------------------------

The MASTER uucico looks in it's spool directory for work to do, if it
sees a work file SNDFILE (S) request, it'll open the file to send as
"read-only".  It it fails, it'll log the message:
	 "FAILED (CAN'T READ ...)".
If the file is not readable by all, it'll log the message:
	"ACCESS (DENIED)"
It'll then set the line for SNDFILE.  After some other stuff, the master 
uucico send a 'SNDFILE message' to the slave.

If the MASTER wants to a file sent to it (RCVFILE - R), it'll check the path
to make sure there's no problem receiving it.

The Sun HDB has an alias ability:

  LOGNAME=Ulong MACHINE=longname ALIAS=longnam COMMANDS=rmail:uucp

Don't forget that '\0377' is 037 octal, not 0377.  Big difference.  You need
to make sure you use no more than 3 octal digits -- it's best to always use
3.  The correct answer is '\377'.

Only way you'll get a SIGHUP is to have CLOCAL off and UIOCMODEM on.  This
doesn't seem to work under A/UX.

--------------------------
IT'S ALL DONE WITH MIRRORS
--------------------------

 Yes, this is the info you all have been waiting for...  How to make the tty
 ports behave so cu, ct and uucico can have a fighting chance at working.

 First, the following compats are required:

    COMPAT_BSDSIGNALS
    COMPAT_BSDGROUPS

 This gives us some reliability on the signals and allows full use of the BSD
 groups feature.  Now, there is one compat you don't want ever:

    COMPAT_SYSCALLS

 This causes some strange behavior on the tty ports that I rather not try to
 explain here.  But let's just say that I would rather not use it.

 Now, keep in mind that no matter what you do, if you set the VMIN/VTIME
 values, perform a read() and it returns 0, this is the EOF.  Don't read no
 more dude!  YOU MIGHT BE SUCCESSFUL, then the misery starts...

 If you want to read or write and DCD isn't present (HSKi), set CLOCAL and
 have at it.  If CLOCAL is clear, then the DCD must be present or you'll get
 the errno EIO on writes and return of 0 on reads.

 If the VMIN/VTIME values are 0 -- good luck.  You can really get confused.

 If you ever get a SIGHUP, let me know, because I've never seen one...

 You should not ground the HSKi, HSKo or GPi pins because the Mac uses
 differential receivers and they require a positive or negative swing in
 voltage with respect to ground.

