Re: [RFC] termios: non-standard baudrates are not handled properly on Linux-systems (BZ#10339)

["H. Peter Anvin" <hpa at zytor dot com>]

On 10/09/18 10:48, Paul Eggert wrote:
> H. Peter Anvin wrote:
>> In other words, B300
>> == 7, so 7 baud would be represented by the value 300.
> 
> I'm afraid I'm confused by this use of "baud_t" and "7 baud". A baud is
> one symbol per second, which in general differs from one bit per second.
> Still, if 7 baud corresponds to 300 bits per second, I'm having trouble
> seeing what's going on. I guess you mean that a speed_t value equal to
> B300 corresponds to a baud_t value equal to 300, but I could well be wrong.
> 
> I suggest giving the new type a name other than "baud_t" to avoid this
> sort of confusion.  "bps_t" or "bits_per_second_t" would be better.

We are talking about *serial ports* here, real or simulated (if one has
a problem with that, consider that we don't have teletypes either these
days.)

The existing, legacy terminology for serial ports is "baud", and
arguably the bps rate for an asynchronous port is *less* than its baud
rate. Consider e.g. the legacy flag name CBAUD.

Furthermore, it is less likely to cause a namespace collision exactly
for this reason.

>> 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.
> 
> Why not use 'float' or 'double' for this? No sense reinventing the
> floating-point wheel.

Because:

1. The precision is less and the exponent far bigger than necessary;
2. Two sign bits are wasted: one for the mantissa, one for the exponent;
3. Idea is such that it identity-maps numbers up to 2^28-1 with
   integers, for compatiblity.
4. At least for Linux, using the FPU in the kernel is a no-no.

I should have clarified that I was talking about speed_t here, not
baud_t, though. My assumption was that baud_t would be a 64-bit integer.

	-hpa