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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 04/10/2018 09:53, Adhemerval Zanella wrote:
> 
> 
> On 03/10/2018 19:13, H. Peter Anvin wrote:
>> On 10/03/18 15:01, Paul Eggert wrote:
>>> On 10/3/18 12:47 PM, Adhemerval Zanella wrote:
>>>> Hans Peter Anvin is advocating for second options [2], with the new
>>>> API as:
>>>>
>>>>   -- Function: speed_t cfgetispeedbps (struct termios *TERMIOS-P)
>>>>       This function returns the input line speed stored in the
>>>>       structure `*TERMIOS-P' as a number of bits per second.
>>>
>>>
>>> speed_t is unsigned int. Is that enough for all devices likely in the
>>> reasonably-near future? I see stories about Arduino serial ports running
>>> at multiple Mb/s, and although that fits it's getting uncomfortably
>>> close to UINT_MAX. USB 3.0 can in theory do 5 Gb/s, which would exceed
>>> 'unsigned int' range, and USB 3.1 and 3.2 are even faster.
>>>
>>
>> speed_t might be 16 bits on some (non-glibc) platforms as far as we know.
>>
>> 	-hpa
>>
> 
> At least for Linux, it seems speed_t is defined as unsigned int for all
> architectures.  It is possible to define the new baud speed abi to take
> a new type with larger range, but we will need to describe its interaction
> with speed_t and it would add more complexity in glibc application without
> much gain.
> 

However I still think tying cfgetispeedbps with speed_t without changing the
Bxxx constants value generates inconsistency, we will have different functions
(cfgetispeed/cfgetospeed) returning the same type with different semantics.

If the idea is keep Bxxx values as is for old programs source compatibility,
I think a better approach is add cfsetispeedbps and cfgetispeedbps without
resorting on speed_t.