[Bug libc/10339] Terminal interface: non-standard baudrates are not handled properly on Linux-systems

["hpa at zytor dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=10339

--- Comment #23 from hpa at zytor dot com <hpa at zytor dot com> ---
I hacked on the above, and the more I work on it, the more I'm unhappy with the
*baud() functions.

The big problem that I see is that an existing application doing getxspeed()
... setxspeed() ought to have a reasonable expectation of returning to the
original baud rate in all circumstances, so an interface which doesn't encode
this information in speed_t is fundamentally broken.

So I came up with this idea:

    speed_t cfencspeed(baud_t)
    baud_t cfdecspeed(speed_t)

... keeping the interfaces using speed_t but having a system-independent way to
encode and decode this abstract type into a true integer. This also becomes a
trivial interface (null transformation) on systems which use speed_t == baud.

On Linux, in order to support the existing Bxxx constants without modification,
we can define the speed_t as a speed, *except* that the Bxxx constants and
their corresponding integers are swapped.  In other words, B300 == 7, so 7 baud
would be represented by the value 300.  Although slightly complicated, this
encoding is 100% efficient, and has the important property of being alias-free,
so that a direct comparison cannot have false negatives.

So far, so good.

Now, assuming we really want to support baud rates over 4 Gbps, I'm thinking of
an interface which might amount to a 5:27 floating point number. no sign bit,
and biased for integers only.  Baud rates below 2^27 ~ 134 Mbps would be
encoded as "denormals"; above that the value will be encoded with an implicit
one, which means that values below 2^28 ~ 268 Mps will still be
identity-transformed with an integer (since 00001 ... would correspond to a
shift of 0 but with an implicit 1, and the implicit 1 would fall into exactly
the same bit position as the 1 in the exponent.)

This would be able to encode baud rates up to to ~288 Pbps with a maximum error
of 4 ppb, without breaking the round-trip property of speed_t and without
having to change the current termios structures (except for SPARC and possibly
MIPS.)

Thoughts?

-- 
You are receiving this mail because:
You are on the CC list for the bug.