On Thu, 11 Nov 1999, Hauke Fath wrote:

> At 0:16 Uhr +0100 09.11.1999, Bill Studenmund wrote:
> 
> I see. Still, I maintain that this is a misconception. When the Macintosh
> Plus came out in 1985, there was no need for flow control with modems (the
> '83 Macintosh did not even have an outgoing handshake line!). According to
> [CAM87], the RTS/CTS pair was used for switching direction on half-duplex
> links.
> 
> And the URL you gave (IM:Devices:Serial Driver) talks about line control,
> only listing in a side note that the SCC DTR pin is actually a general
> purpose output.

Yes, it is a general purpose output, in that the hardware does not perform
the handshaking automatically. Mainly as the hardware handshaking modes on
this chip are hideous.

> >Nope. DTR. HSKo doesn't translate well into NetBSD. For instance, if you
> >use the TIOCMXXX ioctls, this pin is controlled by TIOCM_DTR.
> 
> As that notion is what I propose to fix, it is no good as an argument here. ;)

To be honest, your arguments are coming across as quite forceful, rather
than as a discussion to make things better. :-)

> >Oh. This might explain a lot. I don't think anyone expects the other side
> >to do cdtrcts handshaking, unless it is another mac.
> 
> Yep. And even the other Mac, then, would use RTS semantics on the
> HSKo/"DTR" line.

But what are "RTS" semanitcs? The only types of semantics known by the
driver are flow control and modem control. RTS has never had the monopoly
on flow control - check out the "mdmbuf" flow control mode which has been
around quite a long time. It uses DTR and DCD as the input and output flow
control pins respectivly.

> Probably you can even have your cake and eat it when you tell the modem not
> to hang up unless DTR is low for a certain time (ATS25=255 for a Rockwell
> chip set -- I haven't tried it, though).

I think someone tried that, and it had problems. If anything keeps the tty
input queue from draining for a while, then the modem will hang up,
tearing down your connection in mid stream..

> >Uhm, it's still the DTR pin. It's not cdtrcts because we use DTR
> >semantics, but because we use the DTR pin.
> 
> And if Zilog had named the pin "FOO" we'd call it "cfoocts"? Can't follow
> you there, sorry.

If Zilog had called the pin foo, we would have decided what we wanted to
name it, and have run with that descision.

> >Well, I wasn't the one who came up with this solution. So I'm not the one
> >you need to convice, though I do agree with the decision.
> 
> {When,On which list} was this hashed out? Just so I can go and find out if
> there were any arguments besides "Zilog named the pin DTR"?

Private EMail between me, the port master, and NetBSD's then-chief
architect. And it's not that Zilog named the pin DTR in and of itself.
It's that Zilog and the MI driver calle it the DTR pin. I was wanting to
get away from the hack of using crtscts and mdmbuf simultaneously to get
what we now call cdtrcts..

> >But from the point of view of the kernel, there is no (externally visable)
> >RTS pin, so what sense does crtscts make?
> 
> Describe the semantics? Because the outside world cares about the
> _semantics_ of the line, not about the _label_ that the chip manufacturer
> cared to give the pin?

But the semantics don't matter. It's the name of the pin. While you're
right that we won't just blindly use a manufacturers name, the name
matters. "crtscts" means put flow control semantics on the RTS & CTS pins.
"mdmbuf" means put flow control semantics on the DTR & DCD pins. "cdtrcts"
means put it on the DTR & CTS pins. Also, hupcl controls what happens with
DTR on close. There are a number of other hardware things (some UPS's I
believe) which control power state off of DTR. So there are a number of
different semantics which get layered on top of these pins.

That's why we keep the pin names constant, and use stty modes to control
the semantics we put on these pins.

Take care,

Bill