Arcane modem configuration

[Lerxt]

Summary: Please don't force modem control on me!
Line eater: enabled

In article <1163 at ncr-sd.UUCP>, greg at ncr-sd.UUCP (Greg Noel) writes:
>In article <42 at houligan.UUCP> dave at murphy.UUCP (me) writes:
>>Two problems with this: 1: Some older async interfaces, like the DZ11, do
>>not have interrupts for the modem control lines, so the driver has to poll
>>them.  If you have 80 async ports and most of them are direct-connect, you
>>probably don't want the driver polling all 80 of them for ring indicator
>>continuously.  2: What about current-loop or other non-RS232 interfaces?

>1.  No matter how many ports you have, if \one/ of them has modem control,
>    you have to take the polling interrupt, so you may as well poll them
>    all -- the additional cost is negligible; the expensive part is taking
>    the interrupt.

(Note to anyone who just joined in: this whole section of the discussion is
applicable to older devices like DZ11's, which do not have the capability to
issue an interrupt when a modem control signal changes.)

It's true that the bulk of the overhead is probably in servicing the actual
interrupt.  Still, it seems like a waste of processing time to poll 60+
lines for modem signals when only one or two of them actually has a modem.
Some async devices have registers that take considerably longer to respond
to a read request than memory does.  It seems like if the system was
configured with all of the modem lines in a certain range, the driver could
take advantage of this and set up a for-loop to poll only that range, and then
maybe have flag bits for turning modem control on/off within that range.
Still, I'm willing to admit that checking the flag bits could take as long
as the actual polling.  That isn't the major problem, though.

>2.  What about them?

The point that I was trying to make is that there some terminal interfaces
which simply don't support modem control.  True, some of them are exotic
devices, but some are quite common: there is a widely used version of the
DZ11 that doesn't support modem control signals, and I believe that ports
2-7 on a DMF32 are also of the "transmit-and-receive-only" variety.
What I'm trying to avoid is having some software developer read this
discussion, decide that modem control should *always* be on, and remove the
configuration option for turning it off.  That would cause two problems, one
minor, one major; the minor one is that all lines not actually using modem
control will have to have null-modem cables or adaptor plugs; the major one
is that devices that don't do modem control will be unusuable -- an open on
such a line will never succeed, because it will hang waiting on a carrier
signal that will never appear!

I agree that there should be a way to turn modem control on/off on a line
while the system runs (through some method other than adb :-).  I also agree
that in environments where physical security of the lines is a problem, modem
control should be used on all lines.  At our site, it isn't a problem, so
everything is wired using 3-conductor cable.  As the average terminal line
run is about 1000', and there are probably at least 250 terminal lines in the
building, I doubt that I could convince anyone to rewire the building for
modem control on all lines.

The point is that modem control simply isn't apporpriate in some environments.
Please don't remove the option to disable it.

---
It's been said by many a wise philosopher that when you die and your soul
goes to its final resting place, it has to make a connection in Atlanta.

Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
UUCP:  ...{sun,pur-ee,brl-bmd}!gould!dcornutt
 or ...!ucf-cs!novavax!houligan!dcornutt
ARPA: wait a minute, I've almost got it...

"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."