gemini@geminix.in-berlin.de (Uwe Doering) (09/19/90)
Hello netlanders,
here is FAS 2.07, the Final Async Solution serial port driver.
Like the previous release, FAS 2.06, it supports
- the NS16550A UART chips in full FIFO mode.
- modem sharing for input and output.
- shared interrupts.
- hardware flow control.
New in this release is support for
- VP/ix, the ISC DOS emulator.
- the i82510 UART chips in full FIFO mode.
Additionally, FAS 2.07 is specially tuned to handle multiple
highspeed modems (38400 bps) concurrently (with NS16550A port
chips, of course). This is important for USR HST 14400 modems.
Other vendors will release new highspeed modems as well in the
near future.
And, as usual, there are some bug fixes and several minor improvements.
Here is a list of supported operating systems FAS was successfully
tested on:
Microport UNIX SYSV 3.0
ISC 386/ix 2.0.2 & 2.2
ESIX Rev. C & D
SCO UNIX 386
SCO XENIX 386 2.3.2
If your operating system isn't on the list, don't hesitate to try
FAS. It should work on most 386 based UNIX SYS V flavors.
Have fun!
Uwe
#!/bin/sh
# This is a shell archive (produced by shar 3.49)
# To extract the files from this archive, save it to a file, remove
# everything above the "!/bin/sh" line above, and type "sh file_name".
#
# made 09/18/1990 18:01 UTC by gemini@geminix
# Source directory /usr2/gemini/tmp
#
# existing files will NOT be overwritten unless -c is specified
# This format requires very little intelligence at unshar time.
# "if test", "cat", "rm", "echo", "true", and "sed" may be needed.
#
# This is part 1 of a multipart archive
# do not concatenate these parts, unpack them in order with /bin/sh
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 12423 -rw-r--r-- INSTALLATION
# 26 -rw-r--r-- PATCHLEVEL
# 19473 -rw-r--r-- README
# 19508 -rw-r--r-- RELEASENOTES
# 251 -rw-r--r-- config-ast4
# 253 -rw-r--r-- config-c1-2
# 255 -rw-r--r-- config-c1-3
# 64413 -rw-r--r-- fas.c
# 18415 -rw-r--r-- fas.h
# 144 -rw-r--r-- i_fas-ast4
# 72 -rw-r--r-- i_fas-c1-2
# 108 -rw-r--r-- i_fas-c1-3
# 1279 -rw-r--r-- makefile.ESIX
# 1288 -rw-r--r-- makefile.ISC
# 1300 -rw-r--r-- makefile.SCO
# 283 -rw-r--r-- makefile.XENIX
# 836 -rw-r--r-- makefile.uPort
# 136 -rw-r--r-- n_fas-ast4
# 68 -rw-r--r-- n_fas-c1-2
# 102 -rw-r--r-- n_fas-c1-3
# 26 -rw-r--r-- s_fas-ast4
# 52 -rw-r--r-- s_fas-c1-2
# 78 -rw-r--r-- s_fas-c1-3
# 5588 -rw-r--r-- space-ast4
# 5442 -rw-r--r-- space-c1-2
# 5549 -rw-r--r-- space-c1-3
#
if test -r _shar_seq_.tmp; then
echo 'Must unpack archives in sequence!'
echo Please unpack part `cat _shar_seq_.tmp` next
exit 1
fi
# ============= INSTALLATION ==============
if test -f 'INSTALLATION' -a X"$1" != X"-c"; then
echo 'x - skipping INSTALLATION (File already exists)'
rm -f _shar_wnt_.tmp
else
> _shar_wnt_.tmp
echo 'x - extracting INSTALLATION (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'INSTALLATION' &&
XInstallation guide for the FAS Final Async Solution driver
X----------------------------------------------------------
X
XTo install this driver you need the manual of your serial card,
Xyour system manuals and a certain knowledge about what actually
Xa serial driver is.
X
XYou have to be user root to compile and install the driver!
X
XAttn. Xenix users: You have to copy all FAS files into the
Xdirectory `/usr/sys/conf/fas'! All file modifications you make
Xhave to take place in this directory.
X
X
XCompilation phase
X=================
X
XFirst of all you should copy the makefile that matches your system
Xto the file `makefile'. Make sure that the makefile contains the
Xproper compiler switches, paths and file names for your system.
XYou may also look at `fas.c' and `fas.h' to find out what defines
Xare possible for conditional compilation. In particular, if you
Xdon't link in the original serial driver you might have to uncomment
Xthe `NEED_PUT_GETCHAR' define in `fas.h'. You also may want to
Xuncomment `HAVE_VPIX' in `fas.h' if you have VP/ix support in
Xthe kernel.
X
XAfter that you choose one of the space-xxxxx configuration files
Xthat matches your serial card and copy this to `space.c'. If you
Xdon't find a matching space file you should copy the one that
Xcomes closest to your card to `space.c'.
X
XIn any case you should check the entries in that file against your
Xcard's manual and jumper settings. The space files contain explanations
Xabout what data you have to enter.
X
XIf your `space.c' is filled in properly you simply type `make' to
Xcompile the driver. If you don't get error messages you may begin
Xwith the actual installation. Otherwise you have to find the cause of
Xthe trouble. Some error reasons may be missing include files, macros
Xthat are defined in different include files or missing at all, or you
Xdon't use the standard UNIX 3.X/386 AT&T C compiler. Don't use any
Xother compiler because this may break things. In particular, don't use
Xthe GNU C compiler as it wants to link in some "helpful" routines that
Xaren't in the kernel.
X
XFor SCO Xenix you have to use the Microsoft C compiler because Xenix
Xdoesn't have the AT&T compiler. You will need the ANSI C version of
Xthe Microsoft compiler because the preprocessor of the original
XXenix distribution doesn't understand `#if defined(...)' statements.
X
X
XInstallation phase
X==================
X
XIf you want to have both the original asy (or sio) and the new FAS
Xdriver in the kernel the only restriction is that ports and interrupt
Xvectors can't be shared between the two drivers. Each driver controls
Xits own separate set of ports and IRQs.
X
XuPort: Copy one of the config-xxxxx files to `config'. Check out
X whether the interrupt vectors in this file reflect the
X jumper settings on your serial card. Note that an IRQ2 on
X your card is an interrupt vector of 9. All other IRQ numbers
X correspond to the vector number, though.
X
X Next you have to tell the config program to include the new
X driver at kernel link time. This is done by a line in the file
X /etc/atconf/systems/system.std. Look for the line containing
X `asy' followed by an asterisk (`*') and a comment. Create a
X similar line where `asy' is substituted with `fas'. Add a
X proper comment. If you don't want to use any ports under the
X DOS emulator you should insert an asterisk at the beginning
X of the line that contains the word `asy'. This excludes the
X asy driver from the kernel. But if you want to have it in the
X kernel you have to configure it to only use the ports you
X need under DOS. The remaining ports should be controlled by
X the FAS driver.
X
X Now type `make install' and after that you are ready to link
X a new kernel. Refer to your system manuals on how to do that.
X
X Before you reboot the new kernel make sure that you create
X the proper tty device nodes in /dev. But first you should
X remove all device nodes belonging to the original asy driver
X that you don't need any more.
X
X Now create your own tty device nodes that fit your needs.
X The default device name prefix for the FAS driver is `ttyF'.
X That is, ttyF00, ttyF01 ... and ttyFM00, ttyFM01 ...
X You may choose another prefix, but note that some utilities
X like uustat depend on tty-devices beginning with `tty'!
X
X The default value for the major device number is 4, and
X sane values for the minor device numbers are 48 + device #
X for the dialout node and 208 + device # for the dialin (getty)
X node. Device # counts from 0 and reflects the actual port number.
X Refer to the `README' file for a description of the possible minor
X device numbers.
X
X Remember to change the inittab file to the new device names.
X Other files that contain tty-names for some reason should be
X updated, too (ttytype, Devices etc.).
X
X After you have booted the new kernel, provided your configuration
X was correct, you should be able to use the serial devices.
X
X
XISC: Copy one of the s_fas-xxxxx files to `s_fas'. Make sure
X that you have a separate line in it for each block of contiguous
X port addresses assigned to the same interrupt vector (check
X the jumper settings on your serial card). Each line contains
X the number of ports bound to that interrupt, the start and
X end address of the first (lowest or only) port on this interrupt
X line and other data. Refer to your ISC manuals if you need to
X change this file. Note that an IRQ2 on your card is an interrupt
X vector of 9. All other IRQ numbers correspond to the vector
X number, though.
X
X Then you copy one of the n_fas-xxxxx files to `n_fas'. This
X file contains data needed to automatically create tty device
X nodes at installation time. Things you may want to change are
X the tty node names and the minor device numbers (last field) for
X these nodes. Make sure you have a node for every port on your
X serial card in this file.
X
X Sane values for the minor device numbers are 48 + device #
X for the dialout node and 208 + device # for the dialin (getty)
X node. Device # counts from 0 and reflects the actual port number.
X Refer to the `README' file for a description of the possible
X minor device numbers.
X
X Now copy one of the i_fas-xxxxx files to `i_fas'. This file
X contains the getty lines for the inittab file which is rebuild
X every time a new kernel is installed. Make sure that you use the
X same device names here as in the file `n_fas'.
X
X Next you have to modify the file /etc/conf/sdevice.d/asy in a way
X that only those devices are enabled that you want to be controlled
X by the original `asy' driver. This is done with an `N' in the second
X column of the corresponding line to disable the port and a `Y' to
X enable it. But usually you don't need the original driver any more.
X Therefor all lines in /etc/conf/sdevice.d/asy should be set to `N'.
X
X To tell the kernel config program how to link in the FAS driver
X you have to add the following line to the file /etc/conf/cf.d/mdevice:
X
X fas Iocrwi iHct fas 0 4 1 16 -1
X
X The 6th field contains the major device number of the driver. You
X may change this if it collides with another driver.
X
X All this is in the ISC manuals. Read them carefully.
X
X Now type `make install' and after that you are ready to link
X a new kernel. Refer to your system manuals on how to do that.
X
X You may have to change files that contain tty names to the new
X device names (ttytype, Devices etc.). Take the names from `n_fas'.
X
X After you have booted the new kernel, provided your configuration
X was correct, you should be able to use the serial devices.
X
X
XESIX: Follow the description for ISC UNIX.
X
X
XSCO: Do the same steps as for ISC UNIX. Here are some additional
X hints:
X
X The original SCO serial driver is called `sio' instead of
X `asy'. I don't recommend to leave it in the kernel when
X you use FAS because in an attempt to be "smart" the `sio'
X driver looks for serial ports at known addresses and
X automatically attaches itself to these ports even if
X they are supposed to be handled by the FAS driver. This
X of course will break things.
X
X According to reports from some beta test sites it isn't enough
X to disable the `sio' driver by setting all lines in
X /etc/conf/sdevice.d/sio to `N'. Additionally, you have to
X delete the `sio' entry in /etc/conf/cf.d/mdevice.
X
X In file `fas.h' you need to uncomment the `NEED_PUT_GETCHAR'
X define.
X
X By default FAS has hardware flow control always enabled (minor
X device numbers 48 + device# and 208 + device#, device# counted
X from 0). If you want hardware flow control to be controlled by
X the RTSFLOW and CTSFLOW termio(7) flags the minor device numbers
X are 32 + device# and 192 + device#, respectively. You can change
X this in file `n_fas' before installing the driver. But make sure
X then that all of your programs know about these flags. Otherwise
X you won't be able to use hardware flow control with some of
X these programs.
X
X You have to compile FAS with the AT&T standard C compiler (rcc,
X don't use the Microsoft compiler !) and with the `-DSCO'
X compiler command line flag. The makefile for SCO takes
X care of this, though.
X
X
XXENIX: The installation procedure for Xenix is completely different
X from the other UNIX flavors.
X
X First you should install all other drivers you want to have
X in the kernel.
X
X After this you have to modify the file `/usr/sys/conf/master'.
X There is a line in it that looks like this:
X
X sio 4 0577 104 sio 0 0 5 1 7 3 4 33 34
X
X You have to comment this out with an asterisk (`*') at the beginning
X of the line. Directly after this line you need to insert a new line
X with the following contents:
X
X sio 4 0537 104 fas 0 0 5 1 7 3 4 5 2
X
X The last four columns contain the IRQ numbers used by the driver.
X Make sure that they match the interrupt vectors defined in `space.c'.
X If, for instance, you don't need the last two IRQ fields in this
X line you set them to the dummy values 33 and 34 as it is done in
X the original `sio' line. Don't enter `0' in the IRQ fields you don't
X use because this will prevent the kernel from booting.
X
X Now you have to insert the following line in `/usr/sys/conf/link_xenix'
X (before the lines with the system libs):
X
X ./fas/fas.o ./fas/space.o \
X
X At this point you should be able to link and install the kernel. Use
X the command `hdinstall'. You need to create the FAS device nodes
X manually in the directory `/dev' (with the command `mknod'), for
X example:
X
X mknod ttyF00 c 5 48
X
X Major device number is always `5', the minor device numbers are
X calculated from the README file. If you want hardware handshake
X to be always enabled ttyFxx gets the minor device number 48
X + device# (device# counted from 0) and ttyFMxx gets 208 + device#.
X If you want hardware flow control to be controlled by the RTSFLOW
X and CTSFLOW termio(7) flags the numbers are 32 + device# and 192
X + device#, respectively. But make sure then that all of your
X programs know about these flags. Otherwise you won't be able to
X use hardware flow control with some of these programs.
X
X The last thing you have to do before you reboot your system is
X to modify all the files that contain the device names for your
X original `sio' driver (for programs like `getty', `cu' and `uucico').
X You have to convert all those names to the FAS device names.
X
X
XOther flavors of UNIX
X=====================
X
XCheck out if one of the above installation schemes is similar to the
Xone you need for your system. Make the appropriate changes and try
Xout if it works. If your system is entirely different you have to
Xfind out from your manuals how to install device drivers. But if
Xyou use a UNIX SYSV/386 3.X you should get it to work eventually.
X
XGood luck.
SHAR_EOF
true || echo 'restore of INSTALLATION failed'
rm -f _shar_wnt_.tmp
fi
# ============= PATCHLEVEL ==============
if test -f 'PATCHLEVEL' -a X"$1" != X"-c"; then
echo 'x - skipping PATCHLEVEL (File already exists)'
rm -f _shar_wnt_.tmp
else
> _shar_wnt_.tmp
echo 'x - extracting PATCHLEVEL (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'PATCHLEVEL' &&
Xrelease 2.07 patchlevel 0
SHAR_EOF
true || echo 'restore of PATCHLEVEL failed'
rm -f _shar_wnt_.tmp
fi
# ============= README ==============
if test -f 'README' -a X"$1" != X"-c"; then
echo 'x - skipping README (File already exists)'
rm -f _shar_wnt_.tmp
else
> _shar_wnt_.tmp
echo 'x - extracting README (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'README' &&
XREADME file for the FAS Final Async Solution driver
X---------------------------------------------------
X
XWhat is this package:
X
X This is an async driver for 386 based unix systems that adds
X several features that are not supported by vendors drivers.
X It supports
X
X 1. the NS16550A and i82510 UART chips in full FIFO mode.
X 2. modem sharing for input and output.
X 3. shared interrupts.
X 4. hardware flow control.
X 5. VP/ix, the ISC DOS emulator.
X
X
X FAS was successfully tested under the following operating systems:
X
X Microport UNIX SYSV 3.0
X ISC 386/ix 2.0.2 & 2.2
X ESIX Rev. C & D
X SCO UNIX 386
X SCO XENIX 386 2.3.2
X
X This driver should work with most of the UNIX SYS V/386 3.X ports
X currently available. You can have both this and the original
X vendor driver in the same kernel (if you really like to, but I
X wouldn't know why). Each driver controls its own separate set of
X serial ports. The only restriction here is that any int vector must
X not be used by more than one of the drivers. The kernel config
X program will complain otherwise.
X
X------------------------------------------------------------------------
X
XHow it works:
X
X DIALIN/DIALOUT ON THE SAME PORT
X -------------------------------
X
X This driver supports shared line usage by having two logical
X devices sharing one physical line. Each logical device has its
X own name. For example for the first line the names are ttyF00
X (minor device 0) and ttyFM00 (minor device 192). The ttyF00
X is used for cu, kermit, and other programs that want to dial
X out. It ignores the modem signals and just goes to it. The
X ttyFM00 line is strictly for getty. When getty calls open on
X ttyFM00 the driver hangs the open until the modem asserts the
X carrier detect signal and then lets the open complete. If cu
X opens ttyF00 while getty is waiting for the open to complete
X the device is given to cu and the getty open must wait for cu
X to finish and then will again wait for the carrier. If cu
X tries to open the ttyF00 line while getty has ttyFM00 open cu
X will get an error. If getty tries to open ttyFM00 while cu has
X ttyF00 open the getty open will just hang and wait for cu to
X close the line and then wait for the carrier. To put it simply
X you should put up a getty on ttyFM00 with a -t 60 and use ttyF00
X for cu and uucico.
X
X In the example above ttyF00 had a minor device number of 0 and
X ttyFM00 one of 192. But there are several other possible minor
X device numbers for each port.
X
X The higher bits of the minor device number control the operating
X mode of the device. The port can't be opened by two or more
X different minor devices at the same time.
X
X - Minor devices that *don't* block on open if no carrier is present:
X
X Bitmap: 0 m m h x x x x
X
X `m m' are the mode bits as follows:
X
X 0 0 The carrier signal is totally ignored. With carrier high->low
X *no* SIGHUP signal is generated.
X 0 1 After an initial open, the carrier signal is ignored.
X Although, carrier high->low generates a SIGHUP signal. From
X thereon the device is carrier controlled until the last
X process has closed the device. An ioctl call with a TCSETA*
X command resets the device to ignore carrier again until the
X next carrier high->low.
X 1 0 The device is carrier controlled. Additionally, if on open
X the carrier signal is low, a SIGHUP signal is sent
X immediately.
X 1 1 The device behaves the same as with mode `0 1'. Additionally,
X if on open the carrier signal is low, a SIGHUP signal is sent
X immediately.
X
X - Minor devices that *do* block on open if no carrier is present:
X
X Bitmap: 1 m m h x x x x
X
X `m m' are the mode bits as follows:
X
X 0 0 The device is carrier controlled.
X 0 1 The device is carrier controlled. An unblock signal wakes
X up the waiting open and I/O is possible regardless of
X carrier until a carrier high->low. Thereafter the device
X is again fully carrier controlled.
X 1 0 Same as mode `0 0', but a parallel non-blocking open
X is possible while waiting for carrier.
X 1 1 Same as mode `0 1', but a parallel non-blocking open
X is possible while waiting for carrier.
X
X - Description of the remaining bits of the bitmap:
X
X `h' If set to `1', the device has hardware handshake. Refer
X to the `space.c' file to determine which port signals
X are actually used for that purpose. If set to `0'
X hardware handshake is depending on the termio(7) CTSFLOW
X and RTSFLOW flags (if they are available).
X `x x x x'
X This is the physical port number. This driver supports
X up to 16 ports. If you need more, you should use an
X intelligent serial card because more than 16 devices
X will eat up to much CPU time with this dumb-port approach.
X
X - Note: If a device is carrier controlled, this implies the generation
X of a SIGHUP signal with every carrier high->low. This is of
X course only true if the CLOCAL flag is *not* set.
X
X On my own system I prefer a minor device number of `0011xxxx'
X (48 + device #) for the non-blocking tty node and `1101xxxx'
X (208 + device #) for the blocking tty node. This gives me
X the SIGHUP signal on carrier loss and hardware flow control
X with both logical devices. Dialout while a dialin open
X is waiting for the carrier is also possible with this setup.
X
X
X WHICH SERIAL CARDS ARE SUPPORTED ?
X ----------------------------------
X
X The driver supports and has been tested on many async cards
X and mux boards. It supports most combinations of shared
X interrupts. The current driver supports NS16450, NS16550A,
X um82450 and i82510. 8250 chips are not supported due to various
X bugs and speed problems in these parts. They have no place in any
X 386 or other high performance system. Replace them with one of the
X supported chips. They are pin-to-pin compatible.
X
X Take a look at the various samples of space-xxxx for details
X of how to set up for various devices.
X
X At boot time you will see a status message on the screen with
X symbols that show the init state of each port. The symbols
X are as follows:
X
X - not defined in the fas_port array
X ? can't initialize port
X 1-6 error during test phase indicated by number
X * port is initialized
X f port is initialized and has FIFOs (i82510)
X F port is initialized and has FIFOs (NS16550)
X
X This is convenient to check whether you have entered the proper port
X base addresses in `space.c'.
X
X
X WHICH CARD WILL SUPPORT SHARED INTERRUPTS ?
X -------------------------------------------
X
X Many multi-port cards have jumpers or dip switches that let you
X assign more than one port to the same interrupt (IRQ) line. This alone
X is _no_ guaranty that they really support shared interrupts! These
X cards may be designed for the DOS world where you may want two or more
X serial ports but don't need to run them concurrently, that is, no more
X than one of those ports assigned to the same IRQ line is allowed to be
X in use at a time. For DOS this is sufficient as DOS is no multitasking
X operating system. For UNIX this won't work because in the worst case
X all serial ports may be in use at the same time.
X
X The basic problem is that the PC (and AT) I/O bus can't handle shared
X interrupts itself. This is due to a brain-dead hardware design. Therefor
X there must be some special logic on the serial card to provide shared
X interrupts. And those cards are quite rare (and usually more expensive).
X
X Therefor, you have the choice to give every port on the card its own
X IRQ line or to buy a multi-port card that really has shared interrupts.
X But in the latter case you better ask your vendor twice to make shure
X that it has this functionality because from the card's manuals it often
X isn't obvious which type of card it is. One well-known shared interrupts
X card is the AST 4-port card. There are many compatible clones available
X that are usually much cheaper than the original. You can even buy
X AST compatible 8-port cards where two AST 4-port blocks are on the
X same board.
X
X
X A WORD ABOUT CHARACTER LOSSES
X -----------------------------
X
X If you've experienced character losses with your vendor async
X driver at high baud rates you shouldn't blame the vendor for
X that. The real reason for this problem lies in the ancient port
X devices used in most 386 systems: The 8250 (not supported by
X FAS) and the NS16450.
X
X They have only one receiver character buffer. This implies that
X the operating system must read a character from this buffer before
X the next one arrives from the port's shift register. For the old
X IBM PC with DOS this was sufficient. But for UNIX and with baud
X rates up to 38400 this is simply a joke.
X
X UNIX is not a real-time operating system. That means that it's
X kernel isn't optimized for fast interrupt responses. With the
X proper hardware this is no problem. But because the vendors have
X to adapt UNIX to the standard hardware found in 386 systems they
X also have to cope with the NS16450 ports which are in there simply
X to be compatible with IBM PCs, XTs and ATs.
X
X It is impossible to make it work at high baud rates without a
X major redesign of the AT&T supplied UNIX kernel. But then it
X wouldn't be UNIX SYSV any more.
X
X Luckily, there is a pin-to-pin replacement available from
X National Semiconductors: The NS16550A.
X
X This device has separate 16 character FIFOs for the receiver and
X the transmitter. With these FIFOs the interrupt latency of the
X kernel can be quiet high without losing any characters.
X Additionally, because with most interrupts many characters are
X processed at once the system is loaded much less.
X
X As you see, the necessary hardware is available. Therefor, if you
X have to blame the UNIX vendor then blame him for not telling you
X that you should buy some NS16550A and/or for not supplying you
X with a serial driver that supports these port devices.
X
X But as you have the FAS driver now and if you use the NS16550A
X devices you shouldn't have this kind of trouble any more. This is
X the philosophy behind the driver's name `Final Async Solution'.
X
X Enjoy!
X
X PS: If for some reason you can't get the NS16550A chips you
X could use the i82510 chips from Intel. Although they are
X much less efficient they are still better than the NS16450.
X
X
X HARDWARE FLOW CONTROL
X ---------------------
X
X FAS will support hardware flow control, also known as RTS/CTS
X full duplex flow control, by default. This is a method to control
X character flow in both input and output directions. You can
X enable hardware flow control via the minor device number of the
X port or with the termio(7) RTSFLOW/CTSFLOW flags (if your UNIX has
X them). The RS232C RTS line controls the input direction and the
X CTS line is responsible for the output direction.
X
X As long as the FAS input buffer hasn't reached a certain
X threshold the RTS line is set high to signal the connected
X device that it may send characters. If the input buffer level
X rises beyond this threshold RTS will go low and the device
X is supposed to stop sending characters. As soon as there is
X sufficient space in the input buffer RTS will go high again
X and the character flow may continue.
X
X The CTS line works the other way round. If the connected device
X sets CTS to high the FAS character output is enabled. If CTS is
X low, the output is stopped. There is a special feature for the
X CTS part of the handshake. CTS is only looked at if the DSR
X line is high. If DSR is low or not connected hardware output
X handshake is disabled, that is, FAS sends characters
X regardless of the state of CTS.
X
X This has two advantages. At first, if you switch off a serial
X device connected to an FAS port with hardware flow control
X CTS will go low and therefor the output gets blocked. If at this
X time there are still characters in the output buffer the
X last process closing this port can't terminate until the
X buffer has drained. You can't even kill the process in this
X state. It will become one of those infamous immortal processes.
X But as DSR will also go low if you switch off the device
X this blocking of the output will be prevented. In short:
X Hardware output handshake is only used if the connected
X device sets DSR high, that is, the device is switched on
X and is ready. So make sure that you keep this in mind when
X you make serial cables and when you configure your serial
X devices. DSR must be on if you want CTS handshake.
X
X The other advantage of this CTS/DSR mechanismn is that you
X can still connect dumb serial devices to an FAS hardware
X handshake port using a minimal 3-wire cable. As an unconnected
X DSR line is automatically low hardware output handshake is
X disabled, which is just what you wanted in this case.
X
X
X VP/ix SUPPORT
X -------------
X
X FAS allows DOS programs running under VP/ix to access serial
X ports. You simply need to modify your personal VP/ix configuration
X file (`vpix.cnf') to tell the DOS emulator which FAS devices to
X use for COM1 (or COM1MOUSE) and COM2. Note that VP/ix opens
X these devices at startup time, so you better make sure that
X the desired devices aren't used by other processes when you
X start VP/ix as VP/ix wants to use them exclusively.
X
X There are some special features with the handling of the RTS and
X DTR lines you should know about. If your DOS program asserts
X the DTR line this will actually cause action on the modem
X enable line you configured in `space.c'. Likewise, RTS asserts
X the input hardware handshake line configured in `space.c'.
X
X If the used FAS device has hardware handshake enabled, asserting
X RTS from DOS actually stops the character flow from FAS to VP/ix.
X This prevents input buffers of interrupt driven DOS programs
X from overflowing. FAS, on the other hand, uses its hardware
X handshake to prevent an overflow of its own input buffer. Therefor
X you can use DOS telecommunication programs even at high baud rates
X without losing characters, provided your DOS programs are
X configured to use RTS/CTS flow control.
X
X All this virtual handling has the advantage that the DOS program
X doesn't need to know certain details about your actual port setup.
X Reading the modem status register, on the other hand, doesn't cause
X any translation of the register value.
X
X To enable VP/ix support, you have to uncomment the `HAVE_VPIX'
X define in `fas.h'.
X
X------------------------------------------------------------------------
X
XWhat's in this package:
X
X README This file.
X
X INSTALLATION A description about how to install the driver
X on your system.
X
X PATCHLEVEL Just a reference file for future updates.
X
X RELEASENOTES Notes about the present FAS releases.
X
X fas.h The header file for the driver.
X
X fas.c The driver itself.
X
X space-xxxxx These are samples of what `space.c' must look
X like. You can either copy one of these to
X `space.c' or use it as a template to create your
X own `space.c'.
X
X space-c1-2 For com1 and com2.
X
X space-c1-3 For com1, com2 and com3.
X
X space-ast4 For the AST 4-port card.
X
X config-xxxxx This is for uPort SYS V/386 only.
X Kernel configuaration file. You should pick the one
X that matches your configuration and copy it to `config'.
X
X config-c1-2 For com1 and com2.
X
X config-c1-3 For com1, com2 and com3.
X
X config-ast4 For the AST 4-port card.
X
X s_fas-xxxxx This is for ISC 386/ix, ESIX and SCO UNIX 386.
X Kernel configuration file. You should pick the one
X that matches your configuration and copy it to `s_fas'.
X
X s_fas-c1-2 For com1 and com2.
X
X s_fas-c1-3 For com1, com2 and com3.
X
X s_fas-ast4 For the AST 4-port card.
X
X n_fas-xxxxx This is for ISC 386/ix, ESIX and SCO UNIX 386.
X Tty device nodes file. You should pick the one
X that matches your configuration and copy it to `n_fas'.
X
X n_fas-c1-2 For com1 and com2.
X
X n_fas-c1-3 For com1, com2 and com3.
X
X n_fas-ast4 For the AST 4-port card.
X
X i_fas-xxxxx This is for ISC 386/ix, ESIX and SCO UNIX 386.
X Inittab getty lines file. You should pick the one
X that matches your configuration and copy it to `i_fas'.
X
X i_fas-c1-2 For com1 and com2.
X
X i_fas-c1-3 For com1, com2 and com3.
X
X i_fas-ast4 For the AST 4-port card.
X
X makefile.uPort A makefile for uPort SYS V/386 systems. This is generic
X and should work for all configurations of lines
X and interrupts.
X
X makefile.ISC A makefile for ISC 386/ix systems. This is generic
X and should work for all configurations of lines
X and interrupts.
X
X makefile.ESIX A makefile for ESIX systems. This is generic
X and should work for all configurations of lines
X and interrupts.
X
X makefile.SCO A makefile for SCO UNIX 386 systems. This is generic
X and should work for all configurations of lines
X and interrupts.
X
X makefile.XENIX A makefile for SCO Xenix 386 systems. This is generic
X and should work for all configurations of lines
X and interrupts.
X
X------------------------------------------------------------------------
X
XWhat you will need to use this package:
X
X You will need one of the above mentioned UNIX systems with the
X kernel link kit and the software development package.
X
X------------------------------------------------------------------------
X
XOriginally written by
XJim Murray encore!cloud9!jjmhome!jjm
X2 Mohawk Circle harvard!m2c!jjmhome!jjm
XWestboro Mass 01581 jjm%jjmhome@m2c.m2c.org
XUSA voice (508) 366-2813
X
XCurrent author:
XUwe Doering Domain : gemini@geminix.in-berlin.de
XBillstedter Pfad 17 b Bangpath : ...!unido!fub!tmpmbx!geminix!gemini
X1000 Berlin 20
XGermany
SHAR_EOF
true || echo 'restore of README failed'
rm -f _shar_wnt_.tmp
fi
# ============= RELEASENOTES ==============
if test -f 'RELEASENOTES' -a X"$1" != X"-c"; then
echo 'x - skipping RELEASENOTES (File already exists)'
rm -f _shar_wnt_.tmp
else
> _shar_wnt_.tmp
echo 'x - extracting RELEASENOTES (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'RELEASENOTES' &&
X release 1.1a Sat Nov 11, 1989
X
X This is an unofficial release as I'm not the original author
X of this async driver.
X
X Uwe Doering Domain : gemini@geminix.in-berlin.de
X Billstedter Pfad 17 b Bangpath : ...!unido!fub!tmpmbx!geminix!gemini
X 1000 Berlin 20
X Germany
X
X New Features:
X
X Added a third minor tty device number for every physical
X port. See description preceding the asyopen function in
X asy.c. Changed the behavior of ttyxx, too.
X
X Added output hardware handshake support for DSR. Now you
X can do handshake with CTS, DSR or both. Input hardware
X handshake is on if you use at least one of the output
X handshake signals.
X
X More flexible support of additional interrupt registers
X on mux boards. This is fully configurable now.
X
X Added support for the CREAD flag. If not set, receiver
X interrupts are still serviced, but the received characters
X are simply thrown away. This is not as elegant as disabeling
X the interrupts themselves, but with the already existing
X driver it was the easiest way, and the most new-bugs-preventing,
X too.
X
X Added a lot of comments to the source so that the curious
X user can understand why and how things are done.
X
X
X Bug Fixes:
X
X The hang-up-on-last-close flag (HUPCL) was ignored. DTR
X was asserted regardless of this flag.
X
X Made the detection of CTS and DCD more bullet-proof.
X Especially because between a close and the next open of
X a line, where interrupts are ignored, the software copys of
X CTS and DCD must be set up propperly in the asyopen function
X or the tty line would be blocked under certain circum-
X stances. For similar reasons, there is also a setup in the
X asyparam function.
X
X Rewrote the input character processing function to work
X according to the TERMIO(7) man page.
X
X Changed the behavior of BREAK generation to let the
X transmitter drain before TX is set to low.
X
X Changed line hangup procedure so that the closing
X process returns immediately and doesn't sleep during
X the hangup delay/time. Instead, if an other process tries
X to open the line while hangup is still in progress, this
X process will sleep until hangup is competed.
X
X With DOS Merge, on MicroPort V/386 3.0e the linker was
X missing the function `init8250'. Reengineered this from
X a disassembler listing of MicroPort's original driver and
X modified it to work with the NS16550A 16-byte FIFO. This
X funktion was added simply to be able to link the kernel.
X DOS Merge's virtual COM ports are still unusable with this
X release, though. To include this function, add a `-DMERGE'
X to the CFLAGS line in your makefile.
X
X Made a lot of other corrections and enhancements in both
X speed and functionallity. As a result of all my effords
X I think this driver is slightly faster, more versatile
X and much more stable than the original release.
X
X ------------------------------------------------------------
X
X release 1.1b Sat Nov 25, 1989
X
X New Features:
X
X Changed the minor device number scheme again.
X There are now two main groups: The unblocked open
X and the blocked open. Every group has four sub-modes
X and an additional hardware handshake flag. All this
X is coded in the higher four bits of the minor device
X number. Because of this, the maximum of 32 ports was
X reduced to 16 ports so that the port number fits into
X the remaining lower four bits of the minor device number.
X 32 dumb ports in a single machine would have been overkill
X anyway. For more details refer to the description in the
X README file.
X
X ------------------------------------------------------------
X
X release 2.00 Mon Nov 27, 1989
X
X As this release differs so much from the original version I got,
X I now declare this as independant from the original author
X Jim Murray. This allows me to introduce new release levels
X without wondering whether they will collide with Jim's releases.
X Of course many credits to Jim for writing this software in the
X first place. Without his driver as a base I never would have
X been able to do such kernel driver development.
X
X Bug Fixes:
X
X If there were glitches on the hardware handshake lines
X and the DCD line a getty on this port would sometimes
X hang and become an immortal process. I think this was
X because the output buffer wasn't flushed properly
X on carrier loss. I hope I fixed this now. We'll see.
X
X ------------------------------------------------------------
X
X release 2.01 Tue Nov 28, 1989
X
X Did some cleanup in the source code.
X
X I splitted the driver into two parts: The driver itself and
X the file `space.c'.
X `space.c' contains all data structures necessary to configure
X the driver and is compiled at kernel link time. Therefore if you
X change your serial card configuration you simply change `space.c'
X directly in the link kit directory and relink the kernel. No
X driver recompilation or installation is necessary for this.
X But note that whenever you use `make install' your setup in
X the link kit directory is overwritten by the original `space.c'
X file. Therefore you should copy your new `space.c' back to
X the source directory when you are finished with the configuration.
X
X Renamed the package to `FAS Final Async Solution'. The following
X files have been renamed:
X asy.c -> fas.c
X asy.h -> fas.h
X asy_conf-xxxxx -> space-xxxxx
X
X ISC 386/ix is supported now. There are separate makefiles
X for uPort and ISC to cope with the differences in link kit
X installation.
X
X Bug Fixes:
X
X `getty' still hung sometimes on a line with hardware
X handshake. Tried to fix it this time.
X
X ------------------------------------------------------------
X
X release 2.02 Thu Nov 30, 1989
X
X Abandoned the distinction between space-xxxxx files with
X and without hardware flow control because this is selected
X by the minor device number now.
X
X Bug Fixes:
X
X Set the high and low water marks for hardware input flow
X control to higher values than software flow control. This
X gives precedence to software flow control if both methods
X are used. These marks are self-adjusting and don't need to
X be changed if some flavor of UNIX has a different buffer
X size than the standard 256 characters. Before this change
X concurrent use of both flow controls could cause trouble
X with some high-speed modems. This is fixed now.
X
X A flush read or write buffer request now also clears the
X receiver or transmitter FIFO, respectively. An ioctl
X call with a TCSETA* command clears the FIFOs, too.
X
X ------------------------------------------------------------
X
X release 2.03 Fri Dec 01, 1989
X
X Wrote an installation guide. The driver should be quite
X easy to install now.
X
X Added tty node configuration files for ISC.
X
X Hardware input flow control is bound now to the level of the
X receiver ring buffer instead of the UNIX input buffer. This
X has the advantage that buffer size and trigger levels are
X defined in the driver and therefore can be varied as needed.
X
X New Features:
X
X Added a boot time status message that shows the init
X state of each port. This tells you immediately what
X ports are found and initted by the driver. Useful to
X determine hardware configuration problems. Look at
X the description in the README file. Thanks to
X Kritt Gierlewsen (kritt@einoed.UUCP) for this proposal.
X
X ------------------------------------------------------------
X
X release 2.04 Thu Dec 07, 1989
X
X Did some cleanup in the source.
X
X Removed the FIFO clear from the ioctl function. We don't want
X to do things there that aren't in the book.
X
X An ioctl call that switches off the CLOCAL flag will create
X a SIGHUP signal if the carrier is actually missing at this
X time.
X
X Every device is tested now quite thoroughly during initialization.
X If the test fails the corresponding device keeps unconfigured.
X
X ------------------------------------------------------------
X
X release 2.05 Sat Jan 13, 1990
X
X This is the first public release of the FAS driver.
X
X Special thanks to the sysops of my test sites, Axel Fischer
X (fischer@utower.UUCP) and Kritt Gierlewsen (kritt@einoed.UUCP).
X
X FAS is now an independant driver with its own driver name (`fas'),
X major device number, link kit directory and other things necessary
X for a driver. The original asy driver may or may not be linked
X with the kernel. You only need it if you want to access some
X serial devices via the virtual COM ports of the DOS emulator
X (DosMerge or VP/ix) because the FAS driver doesn't have this
X (really vendor dependant) feature.
X
X The default prefix for tty device node names is `ttyF' now.
X This prevents mix-ups with the device names of the original
X asy driver.
X
X Dropped the SYSV/AT support. I couldn't test the driver
X for several release generations on uPort SYSV/AT, and because
X there are not very much systems left with that flavor of UNIX
X it doesn't make sense to try to maintain compatibility with it.
X If someone really wants to use this driver on a 286 he has
X to port it himself.
X
X Improved the transmitter FIFO fill procedure. Now it will try
X harder to fill the FIFO as much as possible to cut down on
X transmitter interrupts.
X
X Software input flow control (XON/XOFF) is controlled by the driver now.
X It is bound to the level of the receiver ring buffer (as is hardware
X flow control). As usual, it can be switched on and off by the
X IXOFF flag in the termio(7) structure.
X
X Changed and speeded up the ring buffer -> unix buffer processing.
X
X For ISC, the getty lines for the inittab file are installed
X by the makefile now.
X
X The conditional compilation of the function `init8250' (for
X DosMerge) is now controlled by a define in `fas.h'. The compiler
X switch `-DMERGE' is not used any more.
X
X Improved the documentation.
X
X The signals used for modem control and hardware flow control are
X fully configurable in the `space.c' file now. Look at `fas.h' for
X possible macros and combinations.
X
X There are some new modes for hardware flow control, for instance
X HO_CTS_ON_DSR. This means that CTS is only looked at if DSR is on.
X If DSR is off output is possible regardless of CTS. The underlying
X assumption here is that we can expect proper handshake handling
X only from devices that are in the ready state (indicated by DSR).
X As a spin-off the problem with the hanging getty on lines with
X turned-off terminals (mentioned in earlier releases) should be
X gone if you use this new mode.
X
X If the XCLUDE-Flag is availabe (SYSV 3.2 because of Xenix
X compatibility) exclusive open of a device is possible.
X
X The default size of the input ring buffer is now 5000 bytes.
X This makes streaming input more likely even on loaded systems.
X
X Bug Fixes:
X
X The task state busy flag wasn't reset in some rare cases.
X This could cause processes to become immortal while waiting
X for the busy flag.
X
X Under some special conditions an ioctl call with a TCSETA?
X command could corrupt the last character in the transmitter
X shift register. This is fixed now.
X
X More fixing of the busy flag handling was necessary.
X Co-ordinating several delayed tasks controlling this flag
X is kind of tricky.
X
X After a TCSETA* ioctl command we disable the transmitter
X for 2 sec (measured from the last transmitted character)
X if the character format and/or speed has changed. This
X gives the receiving side some time to do the same changes.
X This is kind of experimental. There may be applications that
X suffer from this delay. You may change the #define ADAPT_TIME
X in `fas.h' to a smaller value.
X
X ------------------------------------------------------------
X
X release 2.06 Fri Mar 16, 1990
X
X This should have been patch #3 for release 2.05, but there are
X so many changes now that I decided to make it a new release.
X Therefor some of the changes are described in the 2.05 release
X notes above but were never released to the public.
X
X New Features:
X
X There is a transmitter ring buffer now to make the output
X less system load dependent. This really speeds things up
X because the transmitter FIFO gets filled with more characters
X at once. The buffer size depends on the actual baud rate to
X prevent long output buffer drains at low speeds.
X
X There are also bigger input buffers to make FAS more competitive
X against "intelligent" cards.
X
X Lots of speed improvements and many small changes.
X
X Bug Fixes:
X
X Fixed input/output buffer flush on carrier loss while close
X is waiting for the output to drain.
X
X ------------------------------------------------------------
X
X release 2.07 Tue Sep 18, 1990
X
X This is a major redesign of the previous release. I put most of the
X time consuming tasks in one function that is invoked asynchronously
X by timeout calls. Inside this function most of the code runs at
X a lower system priority level (spl5) than the interrupts. That
X means that during character processing tty interrupts are allowed.
X This is the main key to operation at 38400 bps on multiple ports
X at the same time which is possible now with this release.
X
X New Features:
X
X FAS supports the VP/ix DOS emulator!
X Now you can throw out the vendor's original driver even
X if you like to have a serial mouse or modem access in DOS.
X Read the paragraph about VP/ix in the README file.
X
X The Intel i82510 port chip is supported. It has separate
X 4-character FIFOs for input and output. Although the
X NS16550A is much better this chip is your second choice
X if you can't get your hands on the National chips.
X Thanks to Christian Seyb (cs@gold.UUCP) for sending me
X patches and the necessary documentation for the Intel
X chips.
X
X There is an init sequence in `space.c'. You can put any
X number of address-data pairs in a null terminated array
X to program your serial card or other hardware before
X FAS makes the first access to the ports. AST 4-port cards,
X for instance, have an additional port that needs to be
X written to with a certain bit pattern to allow shared
X interrupts. If you need to read a port to achieve the
X setting or resetting of flags as a side effect, this
X is possible, too.
X
X ESIX is officially supported now.
X
X SCO UNIX is officially supported, too. FAS needs to be
X compiled with the command line flag `-DSCO'. The makefile
X for SCO takes care of that. Thanks to Walter Mecky
X (walter@mecky.systemware.de) and Frank Simon
X (terra@sol.north.de) for helping me in making the necessary
X changes for SCO UNIX.
X
X SCO Xenix 386 is also officially supported. FAS needs to be
X compiled with the command line flag `-DXENIX'. The makefile
X for SCO Xenix takes care of that. Thanks to Andreas
X Steinmetzler (andreas@oil.UUCP) for doing the port.
X
X If you have the RTSFLOW and CTSFLOW termio(7) flags,
X hardware handshake can be controlled by them.
X Note that enabling handware flow control via the
X minor device number overrides these flags. If you
X like to use them you need to create tty device nodes
X with minor device numbers in which the bit for hardware
X handshake is set to 0. Look at the description in the
X README file for more details.
X Note also that if you choose to use RTSFLOW and CTSFLOW
X all your programs that do initial access to tty devices
X (getty, uucico, cu, SLIP dialup program etc.) need to know
X about these flags or hardware handshake will not be used.
X
X The `O_EXCL' flag for the open(2) call is honored now.
X This allowes exclusive access to an FAS device without
X suffering from race conditions which could occure with
X the termio(7) XCLUDE flag method.
X
X The `fas_test_device' function returns a digit now that
X indicates at which phase the test exited due to an error.
X This error digit is displayed in the boot message. Thanks
X to Brian Beattie (beattie@visenix.UUCP) for sending me
X the necessary patches.
X
X Bug Fixes:
X
X Automatic input FIFO flush after unblocking the getty
X open by the carrier or the unblock signal. This makes sure
X that there is no chance that there are characters in the
X FIFO that were received before the open got unblocked.
X
X The sdevice entry for the AST 4-port card had a wrong
X I/O address range (`s_fas-mux4'). This didn't affect FAS
X but is checked by the kernel config program.
X
X The gcc (GNU cc) support was removed because gcc's object
X file wants to link in some "helpful" functions that aren't
X contained in the kernel. But anyway, FAS is tuned so carefully
X and depends on the optimization behaviour of the AT&T
X standard C compiler that gcc won't have any advantages.
X
X I changed the method with which the `fas_test_device' function
X waits for certain events. The `delay' function was used
X for that purpose but it turned out that with some flavors
X of UNIX it is prohibited to use this function during the
X xxinit phase of the boot process. Now a simple timeout loop
X is used instead.
X
X Removed the ADAPT_TIME mechanismn introduced in release 2.05.
X
X The open() call now returns an `EBUSY' error number if the
X device is already open and can't be opened in the desired
X mode at this time.
X
X The handling of the RING signal needed fixing. Unlike the other
X three modem status lines RING generates an interrupt only at
X the trailing edge.
X
X No SIGHUP signal is sent any more if an ioctl call clears
X the CLOCAL termio(7) flag while there is no carrier present.
X SIGHUP is only sent if the actual DCD modem line drops.
X
X The files *-mux4 were renamed to *-ast4 because this type of
X card was originally developed by AST (AST 4-port card).
SHAR_EOF
true || echo 'restore of RELEASENOTES failed'
rm -f _shar_wnt_.tmp
fi
# ============= config-ast4 ==============
if test -f 'config-ast4' -a X"$1" != X"-c"; then
echo 'x - skipping config-ast4 (File already exists)'
rm -f _shar_wnt_.tmp
else
> _shar_wnt_.tmp
echo 'x - extracting config-ast4 (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'config-ast4' &&
X* its character device number 4
Xcharacter(4)
X
X* its name
Xprefix = fas
X
X* The interrupt vectors handled by this controller
Xintvec = 4
X
X* its mask level
Xintpri = SPLTTY
X
X* the functions it supports
Xfunctions = init, open, close, read, write, ioctl, tty
SHAR_EOF
true || echo 'restore of config-ast4 failed'
rm -f _shar_wnt_.tmp
fi
# ============= config-c1-2 ==============
if test -f 'config-c1-2' -a X"$1" != X"-c"; then
echo 'x - skipping config-c1-2 (File already exists)'
rm -f _shar_wnt_.tmp
else
> _shar_wnt_.tmp
echo 'x - extracting config-c1-2 (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'config-c1-2' &&
X* its character device number 4
Xcharacter(4)
X
X* its name
Xprefix = fas
X
X* The interrupt vectors handled by this controller
Xintvec = 4,3
X
X* its mask level
Xintpri = SPLTTY
X
X* the functions it supports
Xfunctions = init, open, close, read, write, ioctl, tty
SHAR_EOF
true || echo 'restore of config-c1-2 failed'
rm -f _shar_wnt_.tmp
fi
# ============= config-c1-3 ==============
if test -f 'config-c1-3' -a X"$1" != X"-c"; then
echo 'x - skipping config-c1-3 (File already exists)'
rm -f _shar_wnt_.tmp
else
> _shar_wnt_.tmp
echo 'x - extracting config-c1-3 (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'config-c1-3' &&
X* its character device number 4
Xcharacter(4)
X
X* its name
Xprefix = fas
X
X* The interrupt vectors handled by this controller
Xintvec = 4,3,9
X
X* its mask level
Xintpri = SPLTTY
X
X* the functions it supports
Xfunctions = init, open, close, read, write, ioctl, tty
SHAR_EOF
true || echo 'restore of config-c1-3 failed'
rm -f _shar_wnt_.tmp
fi
# ============= fas.c ==============
if test -f 'fas.c' -a X"$1" != X"-c"; then
echo 'x - skipping fas.c (File already exists)'
rm -f _shar_wnt_.tmp
else
> _shar_wnt_.tmp
echo 'x - extracting fas.c (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'fas.c' &&
X/* FAS Final Async Solution driver for 386 versions of system V UNIX */
X
X/* Originally written by
XJim Murray encore!cloud9!jjmhome!jjm
X2 Mohawk Circle harvard!m2c!jjmhome!jjm
XWestboro Mass 01581 jjm%jjmhome@m2c.m2c.org
XUSA voice (508) 366-2813
X*/
X
X/* Current author:
XUwe Doering Domain : gemini@geminix.in-berlin.de
XBillstedter Pfad 17 b Bangpath : ...!unido!fub!tmpmbx!geminix!gemini
X1000 Berlin 20
XGermany
X*/
X
X#ident "@(#)fas.c 2.07"
X
X/* Note: This source code was quite heavily optimized for speed. You
X may wonder that register variables aren't used everywhere.
X This is because there is an overhead in memory accesses
X when using register variables. As you may know data accesses
X usually need much more wait states on the memory bus than
X code accesses (because of page or cache misses). Therefore
X saving some data accesses has higher priority than saving
X code accesses.
X
X You may also note some not very elegant constructions that
X may be intentional because they are faster. If you want to
X make style improvements you should check the assembler output
X whether this wouldn't slow things down.
X
X Decisions for speed optimization were based on assembler
X listings produced by the standard UNIX V 3.X/386 C compiler.
X*/
X
X#if defined (XENIX)
X#include "fas.h"
X#else
X#include <sys/fas.h>
X#include <sys/inline.h>
X#endif
X
X#if defined (SCO) || defined (XENIX)
X#define asyputchar sioputchar
X#define asygetchar siogetchar
X#endif
X
X#if defined (XENIX)
X#define intr_disable() old_level = SPLINT ()
X#define intr_restore() (void) splx (old_level)
X#define REGVAR
X
X/*
X** Union for use by all device handler ioctl routines.
X*/
Xunion ioctl_arg {
X struct termio *stparg; /* ptr to termio struct */
X char *cparg; /* ptr to character */
X char carg; /* character */
X int *iparg; /* ptr to integer */
X int iarg; /* integer */
X long *lparg; /* ptr to long */
X long larg; /* long */
X};
X#else
X/* This is a terrible ugly kludge to speed up the `inb' and `outb'
X functions. I.e., originally, the `outb' inline function had an
X overhead of four data memory accesses for parameter passing. This
X parameter passing actually consumed more clock cycles than the
X assembler `outb' command itself. Although this solution can't
X prevent unnessessary register moves it limits them at least to
X register to register moves that are much faster. You need a
X line like the following in the declaration part of every
X function that uses `inb' or `outb' calls:
X
X REGVAR;
X
X This hack should work with every compiler that knows about the
X UNIX V 3.X/386 standard compiler's inline assembler directives.
X*/
X
Xasm void loadal (val)
SHAR_EOF
true || echo 'restore of fas.c failed'
fi
echo 'End of part 1'
echo 'File fas.c is continued in part 2'
echo 2 > _shar_seq_.tmp
exit 0
--
Uwe Doering | Domain : gemini@geminix.in-berlin.de
Berlin |----------------------------------------------------------------
Germany | Bangpath : ...!unido!fub!tmpmbx!geminix!gemini