Return to BSD News archive
Newsgroups: comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!xlink.net!math.fu-berlin.de!easix!flyer!flatlin!bad
From: bad@flatlin.ka.sub.org (Christoph Badura)
Subject: Re: Using the sio ports with a Modem
Organization: Guru Systems/Funware Department
Date: Wed, 4 Aug 1993 09:41:15 GMT
Message-ID: <CB8Aws.H4t@flatlin.ka.sub.org>
References: <1872@dcsc.dla.mil> <1993Jul30.000604.28487@fcom.cc.utah.edu> <23ihduINNpre@kralizec.zeta.org.au> <1993Aug3.051002.2690@fcom.cc.utah.edu>
Lines: 72
In <1993Aug3.051002.2690@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>>(1) if you use only the dialin ports for dialin:
>> keep clocal off always, using something like:
>> stty -clocal before starting getty
>> periodic stty -clocal in case some crazy user turned clocal on
>You lose modem control signals from the modem, notably carrier loss
>notification, which is necessary to cause slattach to realize it has lost
>the connection and it needs to be reestablished (or PPP, for that matter).
I think you have that backwards. If CLOCAL is clear the driver has to
check the modem control signals.
>Also, without DCD drop reconized
>(CLOCAL turns this off), the computer won't drop DTR to the modem, causing
>it to reset as if powered off (if the modem is correctly configured).
I suppose you mean that the programs don't close the device because
they don't get notified about carrier loss. In any case DTR is only
dropped in response to setting the baud rate to B0 or on last close if
HUPCL is set. I don't see how this possibly interacts with CLOCAL.
>The partial open hack is to defeat DCD no present. This is NOT what the
>calling unit devices are for.
IMHO this is exactly what the calling unit devices are for, i.e. to
defeat the partial open hack.
>The calling unit devices are to allow you
>to have inbound and outbound calling on the same device without requiring
>inbound locking
This is a side effect of calling unit devices.
>and to avoid the
>traditionaal shell-script edit of /etc/ttys and SUID "kill -1 1" to kill
>the getty
On which system has this been traditional? Just curious.
>An example of incoming device locks can be seen in SCO's
>uugetty implementation.
Incoming device locks can be seen in *any* uugetty implementation,
that's what uugetty is for. The SCO uugetty/getty is special in that
it locks *both* the dialin and dialout device (at least in some
implementations).
>It probably ought to.
Right.
>The templating of devices is important for getting
>around a program setting O_EXCL on a device file and it being stuck that
>way -- such that only one program can ever have it open.
I dont' see what O_EXCL has to do with the "templating" of the
termio(s) parameters. Could you expand on that.
>Remember that
>close on exec is implied for O_EXCL files/devices even if it is never
>explicitly set.
Is it? Where is that documented? And more importantly where is that
implemented? Certainly not in any SysV kernel I know.
--
Christoph Badura --- bad@flatlin.ka.sub.org --- +49 721 606137
Personally, I don't care whether someone is cool enough to quote Doug
Gwyn--I only care whether Doug Gwyn is cool enough to quote. -- Larry Wall