From comix.santa-cruz.ca.us!news.cichlid.com!nic.scruz.net!miwok!psgrain!xenitec!news Tue Dec 27 21:23:04 1994 Newsgroups: biz.sco.general Path: comix.santa-cruz.ca.us!news.cichlid.com!nic.scruz.net!miwok!psgrain!xenitec!news From: Bela Lubkin Subject: Re: Proper HW/SW config for V.32bis modems Resent-From: mmdf@xenitec.on.ca Submit-To: scogen@xenitec.on.ca Organization: [resent by] The SCOGEN gateway and Propagation Society Date: Wed, 28 Dec 1994 00:19:12 GMT Message-ID: <9412271619.aa13615@srv150a.sco.com> References: <9412261212.aa02606@dlpco.com> <3dnqi0$oag@comix.santa-cruz.ca.us> Sender: news@xenitec.on.ca (xenitec.on.ca News Administrator) Precedence: bulk Lines: 55 This confusion is probably my fault. (Robert Lipe @ Arnet may want to stand up and take a little of the blame too ;-) In 3.2v4.0 and 4.1, you could get bidirectional hardware flow control by using this "CRTSFL" flag that we had invented. If you used "RTSFLOW CTSFLOW", you'd get unidirectional flow control. Robert (and one or two other multiport vendors) pointed out that their drivers too "RTSFLOW CTSFLOW" to mean "bidirectional"; if they had a way to turn on the obsolete unidirectional flow control, it was some more obscure flag. So me & Robert and a few others at SCO came up with this scheme. We'd twist the meaning (and the name) of CRTSFL somewhat, in such a way that we'd have binary compatibility with *both* 3.2v4.1 *and* third party multiport drivers. The only people who would have to change anything would be those using unidirectional flow control -- and we couldn't find anyone doing that, so we figured it would be low impact. Here's how it works. First, the CRTSFL and ORTSFL flags have the same binary value; we redefined the meaning and the name, but (as you'll see) maintained binary compatibility. ======= settings ======== === 3.2v4.0 / 4.1 === === 3.2v4.2 === 1 -ORTSFL -RTSFLOW -CTSFLOW no HW flow control no HW flow control 2 -ORTSFL -RTSFLOW +CTSFLOW ctsflow only ctsflow only 3 -ORTSFL +RTSFLOW -CTSFLOW rtsflow only rtsflow only 4 -ORTSFL +RTSFLOW +CTSFLOW *unidirectional *bidirectional 5 +ORTSFL -RTSFLOW -CTSFLOW bidirectional ("CRTSFL") bidirectional 6 +ORTSFL -RTSFLOW +CTSFLOW illegal illegal 7 +ORTSFL +RTSFLOW -CTSFLOW illegal illegal 8 +ORTSFL +RTSFLOW +CTSFLOW *illegal *unidirectional I've marked with a "*" the settings whose interpretations we changed. In 3.2v4.0/4.1, to get bidirectional flow control you had to turn on an invented flag which wasn't supported by third party multiport drivers. Software written for one sort of board wouldn't work with the other. The third party drivers interpreted "RTSFLOW CTSFLOW" as bidirectional. We changed the interpretation of that combination to match (line 4 above). We also continue to understand that flag by itself to mean bidirectional (line 5); this means we're binary compatible with software written for the SCO driver under 3.2v4.0/4.1. Finally, we renamed the CRTSFL flag, "CTS/RTS FLOW", as ORTSFL, "old RTS/CTS flow". We took over one of the formerly illegal combinations, "CRTSFL RTSFLOW CTSFLOW" and redefined it as "ORTSFL RTSFLOW CTSFLOW", i.e. "Old-style (unidirectional) RTS/CTS flow control" (line 8). We made one mistake in this (besides making sure the doc was completely clear): we should have left both ORTSFL and CRTSFL as recognized synonyms in stty and gettydefs. Aside from that, if you want bidirectional flow control under 3.2v4.2, you can use *EITHER* "RTSFLOW CTSFLOW -ORTSFL" or "-RTSFLOW -CTSFLOW ORTSFL". The former is binary compatible with most intelligent multiport boards. The latter is binary compatible with 3.2v4.0/4.1. >Bela<