Hello all !!!
Can anyone explain what is the utility of the callout devices in the char
drivers ???
Thanks for you attention
regards
--
Henrique Gobbi
[email protected]
On Mon, Mar 11, 2002, Henrique Gobbi wrote:
>
> Can anyone explain what is the utility of the callout devices
> in the char drivers ???
Historically, under various Uni*, the idea was that the callout devices
would ignore DCD so open would complete regardless of the state of the
CLOCAL cflag bit. This allowed dialing on modems that either did not assert
DCD or bobbled DCD (causing hang-up on connect) while switching to online
mode. One would choose to configure modems to assert DCD only when in
connect state to assure local DTR drop (local hang up) if the link got
disconnected. Many phone systems were implemented such that the caller would
remain connected from the point of view of the telephone company and
continue to be billed for time if the called party hung up unexpectedly, or
the phone company dropped the link. Of course, if the modem were configured
to not assert DCD while offline (dialing) then the normal series of tty
devices could not be opened. So, the callout devices were to be used to
"call out" from automatic communication programs such as UUCP.
The other series of devices, sometimes called "call-in", open with CLOCAL
off and wait in open for DCD to be asserted. This is what you would use for
a getty to listen for an auto answer connection. Most vendors provided an
interlock so a single port could be used for call-in and call-out traffic
without conflict. This almost worked. There was always the rare case where
the call-out devices was being opened at the same moment that a call came
in. Not very secure.
There was even a third series of devices that were used to dial out on
hardware separate from the modem in the days before Hayes modems when
dinosaurs roamed the parking lot. :)
Just to confuse things, the vendors noticed that customers were complaining
about not being able to open local connections to directly connected devices
through 3-wire RS-232 and 2-pair RS-422 connections that did not contain the
DCD line. They provided "software carrier" options, not specified via
termio(s) or sgtty that could be set to allow the tty port to act as if DCD
were always asserted. For example, on Solaris this is the default for the
normal tty ports.
To further confuse things, most vendors have a "back door" port
configuration mechanism outside of termio(s)/sgtty. For example, Linux has
the setserial command. There is less need for separate callout devices when
the user can set a port to open with the desired flag values.
In summary, that's why they exist. Don't expect there to still be a
compelling reason to use them.
Enjoy,
----------------------------------------------------------------
Ed Vance [email protected]
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
On Mon, Mar 11, 2002 at 09:59:14AM -0800, Ed Vance wrote:
> On Mon, Mar 11, 2002, Henrique Gobbi wrote:
> >
> > Can anyone explain what is the utility of the callout devices
> > in the char drivers ???
>
> To further confuse things, most vendors have a "back door" port
> configuration mechanism outside of termio(s)/sgtty. For example, Linux has
> the setserial command. There is less need for separate callout devices when
> the user can set a port to open with the desired flag values.
Setserial doesn't have facilities to set open flags for the ports. The
reason cua isn't needed is that the programmer can make a ttyS port look
like a cua port by using the O_NONBLOCK or O_NDELAY flags. However the
non-blocking flag will not only force an open when CD is asserted, but
will make all reads of the port non-blocking. So the programmer can
change this if he wants after the port has opened.
So eliminating cua means more work for the programmer but less confusion
for users. Overall, it's a good thing since there are many more users
than programmers.
David Lawyer
>> > Can anyone explain what is the utility of the callout devices
>> > in the char drivers ???
The utility is this (mind, it is only a nice idea in someone's
empty head, in reality it does not really work that way):
1. You run getty on /dev/cua0 or /dev/cua1.
2. Getty waits for the carrier, and keeps /dev/cuaN open.
3. Meanwhile, you can use cu, kermit, and uucico to dial
out using /dev/ttya or /dev/ttyb.
Sounds very nifty, and this is how SunOS worked and Solaris
tries to (with devices renamed a bit). The devil is details,
or course. The hellishly complicated semantics of this
twin-tailed device makes the driver pretty buggy.
>[...]
> So eliminating cua means more work for the programmer but less confusion
> for users. Overall, it's a good thing since there are many more users
> than programmers.
>
> David Lawyer
I think it's more important that devices work as advertised
more often if drivers are simpler. In my expirience, users
are not really confused by callout devices, but rather are
annoyed when they step on a bug.
-- Pete
On Thu, Mar 28, 2002 at 1:40 PM, David Lawyer wrote:
>
> So eliminating cua means more work for the programmer but less
> confusion for users. Overall, it's a good thing since there
> are many more users than programmers.
Agreed, mostly. My experience is that users prefer system
functionality that is accessible from a shell script, rather than
requiring a source change to their app. The cua method, be it ever
so broken on some platforms, is directly usable without programming
to solve the most common issue - how do I get my app to talk to my
3-wire RS-232 ports.
Good to hear from you again.
----------------------------------------------------------------
Ed Vance [email protected]
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------