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

[hpa at zytor dot com]

On October 4, 2018 6:09:29 AM PDT, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
>
>
>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.

I agree re-using speed_t is a bad idea.

In my wrapper library I posted I created "bps_t".  In retrospect I think we can drop "speed" and call them cf[gs]et[io]bps().

Unfortunately it appears that because Alpha had an oddball ABI – ironically intended to be able to do this all along – setting arbitrary rates was never implanted for Alpha, and *only* Alpha... fortunately it is not *too* hard to deal with this 

I will try to write up a glibc POC patch.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.