Re: [PATCH v5.2 10/12] termios: add new baud_t interface, defined to be explicitly numeric

[H. Peter Anvin]

On May 30, 2025 7:00:57 AM PDT, Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> wrote:
>
>
>On 29/05/25 16:55, H. Peter Anvin wrote:
>> On May 29, 2025 11:55:01 AM PDT, Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> wrote:
>>>
>>>
>>> On 27/05/25 19:08, H. Peter Anvin wrote:
>
>> Ugh, I hate to bikeshed my own proposal, but I'm kind of wondering if we ought to make baud_t either a 64-bit or a floating-point type right off the bat, even if none of the kernels can take advantage of it for now. Anyone had thoughts on that?
>> 
>
>I don't think a floating-point would improve things here, the kernel interface
>would most likely always use integers and libc will need to so the transformation
>anyway. Also, I don't think we will easily seen speed_t requirement larger than
>UITN64_MAX anytime soon.
>
>Using uint64_t would require to rethink the interface idea, since now you document
>that cfgetXspeed get/set the speed_t from the termios struct and changing it size
>would require to either change termios or add a new termios2.  Both options seems
>to add a lot of work that would be used only in future expansions.
>
>> If nothing else I will rewrite the definition a little to say that speed_t == baud_t is not something that is guaranteed in the future.
>
>

The short term implementation would return EINVAL if > UINT_MAX.

Faster than 4 Gbps isn't understandable. The reason for floating point would be that 32 bits fp offer plenty of precision (well above an actual oscillator), and surprisingly enough lines up pretty well with how modern baud rate generators work using a prescaler (shift count/exponent) and an NCO (mantissa)...