Subject: Re: ppp woes continued
To: Bill Studenmund <email@example.com>
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
Date: 11/07/1999 14:49:14
At 8:00 Uhr +0100 07.11.1999, Bill Studenmund wrote:
>On Sat, 6 Nov 1999, Hauke Fath wrote:
>> You want cdtrcts -- which, IMO, is a bad misnomer, because on mac68k it
>> delivers what drtscts promises to do. This is causing all sorts of havoc
>> when you try to run off-the-shelf unix comm applications on mac68k (try to
>> run uucp with hardware flow control =8( ).
>Well, there two reasons we named it like we did. First off, in terms of
>the chip, it really is the DTR line (RTS is used to turn the line drivers
>on and off). Also, a fair amount of Apple serial port documentation talks
>about "DTR" handshaking. :-)
As my Zilog data book says, "[!DTR/!REQA, !DTR/!REQB] These outputs follow
the state programmed into the DTR bit. They can also be used as
general-purpose outputs or as Request lines for a DMA controller."
I.e., if we use HSKo as a flow control handshake line, we _explicitly_
("AT&D0") tell the modem _not_ to monitor the DTR pin. At this point, "DTR
handshaking" is the wrong label - the line does not have DTR semantics, and
no modem out there can be convinced to do flow control _via_the_DTR_line_.
>Though we really should fix all packaged comm stuff to support cdtrcts.
No. We should fix the mac68k behaviour, and not change the rest of the
world to adjust to a misconception. =8)
- renaming the mac68k "cdtrcts" to "crtscts" to sync with
the rest of the world
- keeping around "cdtrcts" for compatibility but making it
clear that it is deprecated (eventually phasing it out)
- creating a new "ccts" tag for unidirectional handshake,
using HSKo with DTR semantics.
- making the mac68k hardware handshake limitations clear in
the zstty manpage. (There is no "ssc" manpage, btw.)
>Please file a PR if we've messed up.
See above. =8)
This has been in the pipe for quite some time, ever since I wasted a few
nights on trying to run UUCP over my ISDN TA just to find out that
everything over 19k2 creates a flood of errors. Diving deep down into the
in-tree Taylor uucp source, I finally found that it had no clue about
mac68k's view on hardware handshake. And I understood that it has the right
not to. ;)
"It's never straight up and down" (DEVO)