> While the following probably isn't the real solution either, I think
> it does sound useful... I think the i386 com driver does this, but I'm
> not sure; I read about it somewhere though :) When the ring buffer is
> about to overflow, and flow control is turned on (crtscts or mdmbuf or
> whatever there is), could you twiddle the flow control line so the
> other end stops sending? This would at least prevent dropping
> characters, which messes up tcp/ip throughput pretty badly :)

We are in the process of switching the serial drivers yet again.

The new version will do this some of the time.

The problem is that we only have one output line. Typically it's
used to hang up the modem. We need a way to choose which way to
go (what to do with the output). The idea is to have crtscts which
will, as at present, use the output for hanging up the modem.
We'll add cdtrcts to use the output for flow control.

This change is all part of us switching to using the M.I. version
of the 8530 driver.

One of the things we're going to lose when we make this change is
the ability to stty one of the serial ports and have the settings stay
for the next open.

Basically, when a serial port goes from unopened to opened, some of the
serial port drivers reset the serila ports to "default" values. Ours
does not. The M.I. one does. Also, resetting to defaults is considered
a "better" way, as it can clean up after a user leaving the port in a
sick state. The stty trick worked as we didn't clear the settings.
It will break when we clear them.

Thus the way the gs driver I put on puma sets the serila port speed is
going to break. It's not a big deal as we now have the ability (in 1.2)
to set the baud rate in the printcap entry, but folks are going to need
to change their setups.

Since there are other uses for setting the default rate, I'm working on
getting the booter to pass in a default speed. That way, you can set the
default speed as you like.

Take care,

Bill