Serial port speed

[gnu at toad.com]

In the effort to merge BSD and Sys V, many things were done right, and a
few were botched.  Serial port speeds are one of the botches.

Sun allocated a 4-bit field for the speed (both incoming speed and
outgoing speed -- they're required to be the same).  The speeds you can
pick among are the same as on the PDP-11 serial ports that Unix was first
written on.

POSIX defined an interface that would let you set the speeds in a more
portable fashion, though they too botched it by requiring portable code to
use #define's like "B1200" rather than simply asking for "1200" baud.  But
their approach, which uses functional macros, permits the implementer to
store the speed any way they want (one 4-bit field or two longwords, or
any other way) and allows the transmit and receive speeds to be set
separately if desired.

UC Berkeley implemented the functional macros such that the "B-defines"
are just the integers, e.g. B1200 == 1200, B19200 == 19200, etc.  The
speeds are passed in longwords and the hardware drivers see them that way.
If the hardware is capable of running at 7 baud, you can set that rate; if
you want 56000 baud, it's there; if you want 1500000 baud, it's there too.
For hardware that only supports a fixed set of baud rates, the attempt to
set 1203 baud (or whatever) can simply fail and return an error.

The botch with Sun's approach is that even companies who care about
providing the ability to set arbitrary speeds, cannot do so in a portable
fashion.  This is because Sun defined the interface between the user
program and the kernel, and does not allow the information to be passed.
When I asked Guy Harris about this in '88, he couldn't think of any reason
that you might want to set a 'nonstandard' serial port speed, and didn't
want to change it.

If you have an application for baud rates beyond the PDP-11 ones, or
higher speeds than 38400 baud, please send a "Request for Enhancement" in
to Sun.  An RFE looks just like a bug report, except they get ignored for
ten releases instead of for one or two.  But by mid-2005 we should have a
software interface that lets us use the capabilities of the built-in
hardware.

	John Gilmore