PD uugetty for Interactives 386/ix?

[Karl Denninger]

In article <NB7IOGG at geminix.mbx.sub.org> gemini at geminix.mbx.sub.org (Uwe Doering) writes:
>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:
>>>
>>>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.

Uh, I don't like that idea.  The port should NOT be unusable, nor should it
be automatically closed.  That's not the idea; to send SIGHUP certainly is.

The former "idea" can leave you with a hung line if something doesn't
release itself when it gets SIGHUP (ie: a hung process, etc).  Unless you've
also fixed the ISC line discipline, this kind of pathological behavior is
easy to produce, and damnable when it happens.  Writing line disciplines is
often harder than doing drivers, especially since it's difficult to locate
ANY documentation on what it's supposed to really do!

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

For outgoing connections AND terminal use?  Half the solution doesn't do
much; if I can run a mouse off it (ie: COM1MOUSE works) then you've got
something.

>>	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.

Equinox finally listened.  Maybe people took my advice literally and beat
them over the head to fix this problem; I don't know, we solved in two weeks
with a Usenet posting what 6 months of asking nicely didn't accomplish.  I
don't have the "fixed" drivers yet, but should within a week.

Much as I hate to say it, most manufacturers work best when you hit them
over the head with a ton of bricks rather than ask nicely.  Too bad, but
'tis life. 

--
Karl Denninger (karl at ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200]
Macro Computer Solutions, Inc.   "Quality Solutions at a Fair Price"