On Sun, 7 Nov 1999, Hauke Fath wrote:

> At 8:00 Uhr +0100 07.11.1999, Bill Studenmund wrote:
> 
> 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_.

Yes, but as you've mentioned, it's hooked up to the dtr pin. ;-) _That's_
why it's cdtrcts.

> >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)

But the misconception is on the other programs' thinking that crtscts is
the only flow control form. From the point of view of the driver, the pin
in question is the DTR pin. When using the ioctls which get & set modem
control line state, this pin is reported / updated according to the DTR
pin settings. If a program wants to go off and do hardware handshaking,
it can't play with RTS & do anything sensable. :-)

> I propose
> 
> -  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.  ;)

"has the right not to?" ??

Take care,

Bill