Return to BSD News archive
Newsgroups: comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Using the sio ports with a Modem
Message-ID: <1993Aug15.231636.17182@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University, Ogden, UT
References: <CBHLwJ.737@flatlin.ka.sub.org> <1993Aug9.213957.18706@fcom.cc.utah.edu> <CBq5Ct.6LH@flatlin.ka.sub.org>
Date: Sun, 15 Aug 93 23:16:36 GMT
Lines: 227
In article <CBq5Ct.6LH@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes:
>In <1993Aug9.213957.18706@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>
>>In article <CBHLwJ.737@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes:
>>>I think you guys implicitly assume that a dial-in and its
>>>corresponding dial-out device must share the same tty structure in the
>>>driver. That need not be the case. In fact, separating the tty
>>>structures simplifies matters and nicely solves the problem of
>>>restoring the tty state on the dial-in device after the dial-out
>>>device has been used.
>
>>Oh no, just the opposite!
>
>The opposite to what? That it solves the problem of restoring the tty
>state?
No, opposite to the topic sentence "you guys implicitly assume...". I agree
with the assertion that the state can be maintained seperately between logical
devices sharing the same physical device, as long as there is some form of
mutual exclusivity protecting the split device mechanism. You might recall
the "transparent printer" example I gave early on in the discussion, where a
seperate state machine is kept to maintain the current state of the device
attached to the serial port to ensure that activity on the logical printer
port occurs only in state 0 on the device. Obviously, the state machine is
not shared between the logical devices -- but there is interaction in terms
of nsuring mutual exclusion.
>> But seperation can't be the only way to solve the
>>problem, since that immediately orphans a lot of multiport cards. For
>>instance, it's possible to use an Arnet 8-port board with the same download
>>binary as for Xenix if one does not make the assumption the the tty struct
>>must be divorced and two must be shared.
>
>That's a broad claim, Terry, and I would like to hear a technical
>reason why you think this is so. I've been thinking about that issue
>the whole week and can't find one.
A multiport card that downloads part of its tty struct to the card, such
that ioctl's to the tty driver in the kernel result not in a kernel state
change but in IPC to the card (and a subsequent state change there) is not
amenable to logical vertical splitting of the device. I can do a split
like the following:
Atomic tty Bipartite
driver tty driver
,--------. ,----.,----.
| ttya | --\ |ttya||cua | <-- IN KERNEL
| A | --/ | A' || A''|
`--------' `----'`----'
But a split for a logically IPC divided driver
Atomic tty Bipartite
driver tty driver
,--------. ,----.,----.
| ttya | --\ |ttya||cua | <-- IN KERNEL
| A | --/ | A' || A''|
`--------' `----'`----'
^ ^ ^
| | |
IPC IPC' IPC''
| | |
v v v
,--------. ,----.,----.
| ttya | --\ |ttya||cua | <-- ON "SMART" BOARD
| B | --/ | B' || B''|
`--------' `----'`----'
Raises the difficulty of having to rewrite the code on the card to understand
the split.
The tranparent printing driver makes the assumption that the tty will be in
the correct mode, so it does not require the split on the "smart" board that
maintaining calling unit state would require if the suggestion that the tty
recognize modem control and the calling unit not recognize modem control
came to pass. The reasoning behind this statement is the implementation of
CTS/RTS hardware and XON/XOF software flow control in the code on the board,
and that the correct treatment of modem-control signals requires that the
board now know how it is being accessed. In particular, I will refer to the
Computone, Arnet, and Digiboard drivers.
>>A state model requiring splitting and seperate maintenance of state for
>>the calling unit and tty unit of a device *dictates* implementation;
>
>So does a model that requires sharing of state. What's your point?
No it does not; it may dictate physical implementation, but the logical
implementation can be done with as many pieces as deemed desirable. For
instance, with the same view of modem control and flow control handling
between the calling unit and the tty device, I can use the same interface
to an existing Atomic tty driver hunk living on the board -- I don't have
to rewrite it.
>> it's
>>a broken model because it disallows some really useful (and preexisting)
>>models for smart boards, and because it is at odds with existing practice;
>
>Using separate tty structs for *dumb* serial boards in no way forces
>you to use the same model for smart boards. I don't see the relevance
>of your argument.
The relevance is that the cannonical processing, virtual terminal handling,
and other code should be shared between devices; by making the model split
visible at the wrong kernel, you either require multiple cannonical processing
modules or you require a rewrite of the on-board code on the "smart" boards
to fit the now visible split.
>It's also not at odds with existing practice. In fact, it works
>rather well. It works so well that lots of sites dropped AT&T's
>non-functional "existing practice" and switched to FAS. After all,
>that was one of the reasons why FAS was developed.
Then port FAS and be done with it; I'll assume that it doesn't require that
consumers rewrite the serial driver portions of applications like uucp, and
if that is the case, iut already obeys the semantics I described with
reference to the SVR3/SVR4 serial drivers... ie: it doesn't break the
existing practice codified in hundreds of applications.
>Further, your "existing practice" requires such hacks like uugetty
>busy waiting when a process is using its port for dial-out, or worse,
>requiring that an application that wants to use a dial-in port for
>dial-out to disable the getty and reenable it when it's done (which it
>may not be able to, because it missed to catch a signal).
Wrong. First of all, signals are persistant conditions, not events, so the
"missing a signal" scenario is impossible without broken signals (my example
ensured the alarm would be recalled (*not* in the handler), and if the signal
occurs, it *will* be delivered -- the inherent unreliability of signals is
due to multiple signals not being queued, not because it is possible to not
assert the condition. This is fixed in draft POSIX 1003.4, by the way).
If you will reread my article
Subject: Re: Using the sio ports with a Modem
Message-ID: <1993Aug5.045537.13166@fcom.cc.utah.edu>
You will see that I explain the uugetty sleep/wakeup loop as resulting from
a fear of bad serial drivers (improper O_EXCL implementation), and not from
any real need. I stated that it was a bad thing. Noting that a bad thing
exists is a far cry from recommending that it be used by others. The entire
idea of uugetty is stupid and unnecessary. The only conceivable use is in a
direct serial connection between two systems that must be allowed to uucp
both ways. A more appropriate soloution would be PPP or SLIP.
>>we should not bite off on unnecessary maintenance because we have a "better"
>>way of doing things
>
>A working driver beats defunct "existing practice" any day.
I agree; it would be nice if I were free to write one. I'm not, and you are
well aware why. The idea is not to codify existing practice (although there
is much merit in adopting a lot of Sun's approaches), but to allow programs
that do serial I/O (such as the GNU FAX package) to operate as expected. I
am not suggesting that we take AT&T's approach, only that we learn from it.
>>Remember, further,
>>that network pseudo-devices used for modem pooling won't be able to
>>handle the split model either
>
>I don't recall that you've mentioned that fact before. Maybe you want
>to explain to us *why* that is so.
Because the other side of the connection already exists and we have to conform
to existing practice to talk to it. I have mentioned it in the past the last
time this discussion cropped up (on comp.unix.bsd). Whether or not it has
been brought up in the past in this discussion is irrelevant to the point:
I have brought it up now.
The "why" is because modem pooling software is exactly analagous to the idea
of a bipartite com driver; the serial port is accessed and returns its state
information when queried by means of an IPC mechanism; that this takes place
over a network instead of in the kernel is irrelevant.
>> (and *will* require templating to allow for
>>a known state after DCD drop).
>
>I wonder what this mysterious "templating" that you're constantly
>referring to *really* means. How about giving us a complete
>specification?
Templating simply refers to the fact that there is a known state to which the
device is returned when it goes to its idle state. Everything that can not
be guaranteed to be in the local half of a bipartite driver (ie: smart card
or modem pool), like baud rate, flow control, etc. has a default value that
it is forced to. This provides a synchronization point for state reset for
the initial state of the lower half of a bipartite driver to be known to the
upper half. It also allows the default continuing operation of programs like
getty, which may not set all of the state information for a driver, but will
expect to be able to work by providing deltas from an assumed default.
Basically, this means that a device driver will have initialization defaults
for flow control, parity, baud rate, word length, and other parameters which
may not be known to the consumer. It also means that if I stty a port to
a particular baud rate, the baud rate stays only as long as there exists an
open instance for the device, and that its reset after the last open reference
goes away. This is consistant with the fact that there will not necessarily
be rest notification on on-to-off DCD transition from a remote device, and
such resets *must* occur to ensure a reliable state for the next usage.
For instance, say I have a Vista terminal server with a modem attached to it,
and I would like to be able to allocate the port for dialout; the allocation
of the port is done "transparently" by the device driver in the kernel, which
is a loopback (maybe known as /dev/vs0) into user space that will establish
a network connection allocating the Vista port on open, and deallocating it
on close.
The Vista terminal server has a default baud rate for that port (this is
the way the things work); if I "stty 9600 < /dev/vs0", the device is opened,
the network connection established, the baud rate set, the device closed, and
the network connection closed. The Vista now sets the baud rate to its
"templated" value, since the connection reset causes it to go back to its
default state. Now, I open it with a comm program that doesn't set the baud
rate (after all, I know I set it to 9600) and get indeterminate results.
Even if the terminal device driver you end up with does not do templating,
user software can not assume that it does not occur. Therefore there is
no basis for the argument that "templating decreases functionality" because
an application writer *must* assume that it is occurring anyway for the
application to be portable. Any sacrafice which occurs to avoid templating
is a waste, and the stupid "stty -clocal" before calling out falls into that
category.
Terry Lambert
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.