PD uugetty for Interactives 386/ix?

[Uwe Doering]

karl at ddsw1.MCS.COM (Karl Denninger) writes:

>In article <9009011253.AA13674 at esegue.segue.boston.ma.us> johnl at esegue.segue.boston.ma.us (John R. Levine) writes:
>>
>>Rather than using uugetty, use either the async driver on the X5 or X6
>>update disks, or else the public FAS driver posted here.  Both of them
>>provide separate /dev entries for dialin and dialout, so you can run a
>>modem both ways without uugetty.  I have used both, and they both work.
>>
>>FAS is somewhat faster, X5/X6 supports VP/ix.  Both take advantage of
>>the extra buffering in a 16550 ASYNC chip.
>
>That does NOT solve one problem:
>
>o You dial out on the non-modem control port.  The call completes, then
>  drops.  How do you detect it?  The answer?  You don't!

This isn't true for FAS. Even on the dialout port you have (by default)
modem control, that is, the processes on the port get the SIGHUP signal
if the carrier drops, and from thereon the port is unusable until it
is again set up by an ioctl call or it is closed. Therefor you don't
need to change anything on your system to do proper dialin/dialout on
the same port. But on the other hand, having `getty' sources isn't
a bad thing anyway.

BTW, FAS 2.07 (not yet released) _will_ have VP/ix support. You won't
need the X5/X6 drivers any more. :-)

>	ISC does not correctly support CLOCAL on modem control lines.  If
>	you open a port with O_NDELAY, then set CLOCAL and clear O_NDELAY
>	with fcntl, you should get BLOCKING reads with the CD signal
>	ignored.  Instead you get non-blocking reads if CD is low, and
>	blocking reads if CD is high (idiots!).
> [stuff deleted]
>	Unfortunately, Equinox and a few other board makers have mimiced the
>	broken code instead of fixing it (double idiots!).

Just to be complete, FAS doesn't have this bug.

     Uwe
-- 
Uwe Doering  |  USA      : gemini at geminix.mbx.sub.org
Berlin       |  World    : gemini%geminix at tmpmbx.UUCP
Germany      |  Bangpath : ...!{backbone}!tmpmbx!geminix!gemini