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

[H. Peter Anvin]

On 6/2/25 05:42, Adhemerval Zanella Netto wrote:
> 
> On 30/05/25 17:31, H. Peter Anvin wrote:
>> 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)...
> 
> Would be better to when/if kernel supports such values to decompose speed_t in
> an struct/union with the prescaler/NCO instead along with a extra flag to handle
> the speed_t in a different manner than an integer? 
> 

Well, what you're basically suggesting is reinventing floating point :)

As far as floating point versus uint64_t... the latter is certainly fine
for high values, but the precision is poor at the low end (45.45 and
134.5 being example of legacy baud rates that aren't well represented as
integers.)

Either way, I think you're right... let's burn that bridge when we get
to it. However, I think changing the documented phrasing to not assume
speed_t and baud_t are the same is the right thing.

	-hpa