Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!bu.edu!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!unido!tub!tmpmbx!geminix!gemini From: gemini@geminix.mbx.sub.org (Uwe Doering) Newsgroups: comp.unix.sysv386 Subject: Re: PD uugetty for Interactives 386/ix? Message-ID: <3QBJ5BI@geminix.mbx.sub.org> Date: 10 Sep 90 15:37:15 GMT References: <9009011253.AA13674@esegue.segue.boston.ma.us> <1990Sep03.060502.27179@ddsw1.MCS.COM> <1990Sep09. Organization: Private UNIX Site Lines: 93 karl@ddsw1.MCS.COM (Karl Denninger) writes: >In article gemini@geminix.mbx.sub.org (Uwe Doering) writes: >>karl@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@geminix.mbx.sub.org Berlin | World : gemini%geminix@tmpmbx.UUCP Germany | Bangpath : ...!{backbone}!tmpmbx!geminix!gemini