readme

一个通讯程序源码

          The other advantage of this CTS/DSR mechanismn is that you
          can still connect dumb serial devices to an FAS hardware
          handshake port using a minimal 3-wire cable. As an unconnected
          DSR line is automatically low hardware output handshake is
          disabled, which is just what you wanted in this case.

     Half duplex mode:

          There are actually three half duplex modes selected by
          the minor device number:

          First mode:
             If the RTSFLOW termio(7) flag is set _and_ the CLOCAL
             flag is _not_ set the RTS line is used to signal the
             connected device that there is data in the output buffer.
             As long as there is output data to come the RTS line stays
             high. If the output buffer has drained RTS drops to low
             until there is more data to be sent to the connected device.

             If the CTSFLOW termio(7) flag is set _and_ the CLOCAL
             flag is _not_ set the CTS line used to control the output
             character flow. This works as in full duplex mode.

          Second mode:
             This mode overrides the RTSFLOW/CTSFLOW flags and works
             as if the CTSFLOW flag is set permanently. The CLOCAL flag
             doesn't affect this mode.

          Third mode:
             This mode overrides the RTSFLOW/CTSFLOW flags and works
             as if both the RTSFLOW and CTSFLOW flags are set permanently.
             The CLOCAL flag doesn't affect this mode.


     CABLING
     -------

     Don't leave unused input lines (CTS, DCD, DSR, RING) open! Due
     to crosstalking from other lines these input lines might change
     their logic level rapidly, resulting in excessive modem status
     interrupts that could bring your machine down to its knees.
     Therefor you should connect any unused input line to GND (pin 7
     on the D-Sub 25 RS232C connector).

     To prevent the machine from locking up in a case like described
     above the port causing the modem status interrupts will be shut
     down for 30 seconds after the last close on that port. Any attempt
     to use an open(), read(), write() or ioctl() call to this port
     during the time until the last close and then 30 seconds from
     there will result in an ENXIO error.

     The port shutdown will be indicated on the system console by a
     warning message containing the unit number of the offending port.

     But even if this protection mechanismn isn't triggered on your
     computer you might have this problem. This is usually indicated
     by a bad system performance during high speed serial data transfers.
     Use your system's performance measurement tools to check the
     number of modem interrupts. If it is unusual high, or even
     higher than the number of transmit/receive interrupts, you
     certainly have a problem with your cabling. Of course, another
     reason could be a bad port chip.

     ATTENTION: If you want to connect two UNIX systems (both using
     FAS) via a null modem cable, and if you want to run a getty
     on both ends you need to modify the `space.c' file to prevent
     both gettys talking to each other, wasting valuable CPU time.
     Remove the `EI_DTR' (or `EI_RTS', depending on your setup) macro
     for the desired port from the initializer part of the `fas_modem'
     array. This will cause DTR (or RTS) to be asserted only on
     dialout. Therefor, the getty at the other end will become alive
     only if a dialout is in progress.


     VP/ix SUPPORT
     -------------

     FAS allows DOS programs running under VP/ix to access serial
     ports. You simply need to modify your personal VP/ix configuration
     file (`vpix.cnf') to tell the DOS emulator which FAS devices to
     use for COM1 (or COM1MOUSE) and COM2. Note that VP/ix opens
     these devices at startup time, so you better make sure that
     the desired devices aren't used by other processes when you
     start VP/ix as VP/ix wants to use them exclusively.

     There are some special features with the handling of the RTS and
     DTR lines you should know about. If your DOS program asserts
     the DTR line this will actually cause action on the modem
     enable line you configured in `space.c'. Likewise, RTS asserts
     the half duplex hardware handshake line configured in `space.c'.

     If the used FAS device has full duplex hardware handshake enabled,
     asserting RTS from DOS actually stops the character flow from FAS
     to VP/ix. This prevents input buffers of interrupt driven DOS
     programs from overflowing. FAS, on the other hand, uses its hardware
     handshake to prevent an overflow of its own input buffer. Therefor
     you can use DOS telecommunication programs even at high baud rates
     without losing characters, provided your DOS programs are
     configured to use full duplex RTS/CTS flow control.

     All this virtual handling has the advantage that the DOS program
     doesn't need to know certain details about your actual port setup.
     Reading the modem status register, on the other hand, doesn't cause
     any translation of the register value.

     To enable VP/ix support, you have to uncomment the `HAVE_VPIX'
     define in `fas.h'.


     DEVICE LOCKUPS
     --------------

     There are certain conditions under which a device can lock up,
     that is, at least one process that uses this device waits for
     a tty I/O related event that obviously doesn't occure.

     The most common case is that there are still characters in the
     output buffer, but the output is disabled for some reason. Then
     the last process that closes the tty device hangs in the close()
     function until the output buffer has drained.

     Tty output may be stopped by the software (XON/XOFF) or hardware
     (RTS/CTS, by default) flow control. In this case something
     seems to be wrong with the cabling or the connected device.
     Please check this first out before you blame FAS. Sometimes
     it helps to switch the device off and on a few times to unblock
     the tty output.

     Another reason could be a lost transmitter interrupt. This usually
     indicates a hardware problem in your computer which should be fixed
     as soon as possible. Otherwise, you can't run this system unattended
     because it is too unreliable.

     In the cases described above the last resort is entering `kill -9 <pid>'
     once or twice. This should unblock and terminate the hanging process.

     And there is a rare case which has to do with the number of available
     CLISTs in the UNIX kernel. The CLIST output and input buffers are
     256 bytes each (by default). If for some reason the output of a
     tty device is stopped but a process continues to send data one
     character at a time this uses up one CLIST for every charcacter.
     If the number of CLISTs in the kernel is less than 256 all CLISTs
     will be busy eventually.

     The dangerous part here is that the pool of CLISTs is used by all
     tty devices. Therefor, if one single tty device manages to eat up
     all available CLISTs all tty in- and output comes to a halt. If this
     happens you can't access your machine any more, not even from the
     operator console. Although, the system is still alive internally.

     Unfortunately, many UNIX vendors have put a dangerously low number-of-
     CLISTs parameter into their kernel tune files. You should increase
     it to a value that makes it impossible that one device alone can
     occupy all CLISTs (it's the NCLIST parameter under AT&T derived
     UNIX SysVr3.x). A value of 400 should be sufficient.

------------------------------------------------------------------------

What's in this package:

     README         This file.

     INSTALLATION   A description about how to install the driver
                    on your system.

     PATCHLEVEL     Just a reference file for future updates.

     RELEASENOTES   Notes about the present FAS releases.
                    
     fas.h          The header file for the driver.

     fas.c          The driver itself.

     space-xxxxx    These are samples of what `space.c' must look
                    like.  You can either copy one of these to
                    `space.c' or use it as a template to create your
                    own `space.c'.

          space-c1-2     For com1 and com2.

          space-c1-3     For com1, com2 and com3.

          space-ast4     For the AST 4-port card.

          space-hub6     For the Bell Tech HUB-6 card.

     config-xxxxx   This is for uPort SYS V/386 only.
                    Kernel configuaration file.  You should pick the one
                    that matches your configuration and copy it to `config'.

          config-c1-2    For com1 and com2.

          config-c1-3    For com1, com2 and com3.

          config-ast4    For the AST 4-port card.

          config-hub6    For the Bell Tech HUB-6 card.

     s_fas-xxxxx    This is for ISC 386/ix, ESIX, Bell Tech/Intel UNIX 3.2
                    and SCO UNIX 386.
                    Kernel configuration file.  You should pick the one
                    that matches your configuration and copy it to `s_fas'.

          s_fas-c1-2     For com1 and com2.

          s_fas-c1-3     For com1, com2 and com3.

          s_fas-ast4     For the AST 4-port card.

          s_fas-hub6     For the Bell Tech HUB-6 card.

     n_fas-xxxxx    This is for ISC 386/ix, ESIX, Bell Tech/Intel UNIX 3.2
                    and SCO UNIX 386.
                    Tty device nodes file.  You should pick the one
                    that matches your configuration and copy it to `n_fas'.

          n_fas-c1-2     For com1 and com2.

          n_fas-c1-3     For com1, com2 and com3.

          n_fas-ast4     For the AST 4-port card.

          n_fas-hub6     For the Bell Tech HUB-6 card.

     i_fas-xxxxx    This is for ISC 386/ix, ESIX, Bell Tech/Intel UNIX 3.2
                    and SCO UNIX 386.
                    Inittab getty lines file.  You should pick the one
                    that matches your configuration and copy it to `i_fas'.

          i_fas-c1-2     For com1 and com2.

          i_fas-c1-3     For com1, com2 and com3.

          i_fas-ast4     For the AST 4-port card.

          i_fas-hub6     For the Bell Tech HUB-6 card.

     Makefile.uPort A makefile for uPort SYS V/386 systems. This is generic
                    and should work for all configurations of lines
                    and interrupts.

     Makefile.ISC   A makefile for ISC 386/ix systems.  This is generic
                    and should work for all configurations of lines
                    and interrupts.

     Makefile.ESIX  A makefile for ESIX systems.  This is generic
                    and should work for all configurations of lines
                    and interrupts.

     Makefile.BELL  A makefile for Bell Tech/Intel UNIX 3.2 systems.  This
                    is generic and should work for all configurations of
                    lines and interrupts.

     Makefile.SCO   A makefile for SCO UNIX 386 systems.  This is generic
                    and should work for all configurations of lines
                    and interrupts.

     Makefile.X386  A makefile for SCO Xenix 386 systems.  This is generic
                    and should work for all configurations of lines
                    and interrupts.

     Makefile.X286  A makefile for SCO Xenix 286 systems.  This is generic
                    and should work for all configurations of lines
                    and interrupts.

------------------------------------------------------------------------

What you will need to use this package:

     You will need one of the above mentioned UNIX systems with the
     kernel link kit and the software development package.

------------------------------------------------------------------------

The original asy replacement driver for Microport UNIX/386 (FAS' predecessor)
was developed by

Jim Murray              INET            [e-mail]
2 Mohawk Circle         UUCP            harvard!m2c!jjmhome!jjm
Westboro Mass 01581     
USA                                     voice [phone]

Credits to him for releasing this great driver to the Usenet community.
But if you have problems with FAS please don't contact him because he
wasn't involved in the developement of FAS.

FAS was developed by [BUT DON'T BOTHER HIM ABOUT FAS/i]

Uwe Doering             INET : [e-mail]
Billstedter Pfad 17 b   UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
1000 Berlin 20
Germany

------------------------------------------------------------------------------
For FAS/i inquiries:
   Warren Tucker [e-mail], emory!n4hgf!wht

    ^    ^    ^    ^    ^    ^    ^    ^    ^    ^
Send your questions and bug reports to this address.