>>The "standard" for inbound flow control (the computer says "wait" when
>>its buffers are full) is a relatively new invention for RS232. The
>>most-common method seems to be to overload the meaning of RTS/CTS again
>>and have the DTE (computer) drop RTS when it's full, to tell the modem
>>not to send any more. The Solaris serial drivers are being updated to
>>conform to this emerging standard. Until that time, inbound
>>flow-control is software-only. We realize this is a problem and are
>>working to fix it. Watch for a driver update soon.
>RTS/CTS flow control for full duplex transfers was standardized
>in RS232-E, a couple of years ago.
...and RS232 has been around a lot longer than a couple of years,
and so has Unix, and there's an awful lot of backward-compatibility
stuff in the serial drivers. I didn't mean that no one at Sun was
aware of it, just that a lot of changes have gone on in various
standards for serial port hardware use as well as serial port
software convention, and SunSoft is trying to ride them all.
We're finally getting to hardware-flow-control with RTS/CTS,
and it's probably overdue, but this is why; go try to make sense
of SVID, XPG4, and "existing practice" in all the Unix clones.
It's no fun.
Quote:>You said "overload ... again".
>Is that redundant tautology or is there really a third
>use for the signal lines?
The three I meant were
1) the original: RTS means "the DTE is ready" and CTS means "The DCE
is ready"; RTS is established at the beginning of a session and not
dropped, and CTS is used mostly for half-duplex turnaround time
2) the "but I need some flow control from DCE to DTE" mode, where the
terminal/computer is faster than the modem, so the modem needs to
say "hang on" by dropping CTS during the course of a session
3) the "but we need flow-control *both* directions", where RTS
and CTS are used for the corresponding flow-control
I didn't mention
4) Other signals are pressed into use as hardware flow-control,
>I was astounded to find that rts/cts
>was not supported on solaris x86. It is the only PC operating
>system I know of that doesn't support it and you can't use the
>argument we've been getting for years in the SPARC world that the
>Zilog hardware doesn't support it. Anyway, glad to hear you guys
>are getting finally around to it.
>Andrew Fullford a.out computer consultants