PD uugetty for Interactives 386/ix?

[Uwe Doering]

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

>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:
>
>>>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!

I haven't fixed the line discipline. First, the design goal for the
dialout ports with modem control was that their behaviour is the same
as with getty ports, with the only difference that they ignore the
DCD line until this line goes to high. After that it will behave
exactly like the getty ports.

When I sayed that the port is unusable after a DCD drop I meant that it
does the same as a getty port after a DCD drop: Read and write system
calls return immediately with a result of 0 which should be detected
as an error by any well-written program (`uucico' does this, and other
programs as well). Therefor you won't have hung processes.

The worst thing that could happen is that a program is brain-dead enough
to go into an infinite loop if it ignores the SIGHUP signal and doesn't
check the read/write return values. But that's not a problem with the
serial driver. It's a problem with the application programmer not knowing
what he's doing.

If I would leave the port enabled after the DCD drop a program that ignores
SIGHUP would continue to receive and send data, and this could easily
lead to a nice chat between the modem and the program because the modem
is in the command mode after a DCD drop. This is definately not what
should happen! This could even destroy your EEPROM modem setup as all
these things usually follow Murphy's Law. :-(

I can assure you that there are only few (if any) problems with real-
world applications and FAS. This DCD behaviour was the same with all
previous releases of FAS, and I yet have to find a program that refuses
to work on the dialout port. I haven't got any reports about this issue,
either.

Therefor, I still think it's much worse to let a program read/write
from/to the port when it isn't supposed to, than to disable the port
until the program explicitely sets it up again either by closing and
reopening the port or by an ioctl call with the TCSETA{W|F} command.
As I said this works with all the programs I've used so far. And
if a program wants to ignore DCD completely it can do so by setting
the CLOCAL termio(7) flag.

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

Yes, COM1MOUSE works as well as COM1, and you can use COM2 at the same
time. I've used the telecommunication program Telemate 2.10 to talk
to a modem on COM2 while I could move the mouse cursor with a mouse
on COM1.

And if you dial in via a modem (or have a dos mode terminal connected
to the computer) you can start VP/ix directly on this serial line.
I tried this with a VT100 terminal emulation and to my surprise I
could use several fullscreen DOS applications. :-) Even if the modem
carrier drops while you are in VP/ix the DOS emulator won't hang the
line but instead will exit due to a SIGHUP signal.

Karl, is this what you had in mind?

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