[Bug libc/10339] Terminal interface: non-standard baudrates are not handled properly on Linux-systems

["hpa at zytor dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=10339

--- Comment #25 from hpa at zytor dot com <hpa at zytor dot com> ---
On 10/10/18 12:28, adhemerval.zanella at linaro dot org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=10339
> 
> --- Comment #24 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
> (In reply to hpa@zytor.com from comment #23)
>> I hacked on the above, and the more I work on it, the more I'm unhappy with
>> the *baud() functions.
>>
>> The big problem that I see is that an existing application doing getxspeed()
>> ... setxspeed() ought to have a reasonable expectation of returning to the
>> original baud rate in all circumstances, so an interface which doesn't
>> encode this information in speed_t is fundamentally broken.
>>
>> So I came up with this idea:
>>
>>     speed_t cfencspeed(baud_t)
>>     baud_t cfdecspeed(speed_t)
>>
>> ... keeping the interfaces using speed_t but having a system-independent way
>> to encode and decode this abstract type into a true integer. This also
>> becomes a trivial interface (null transformation) on systems which use
>> speed_t == baud.
> 
> It is not clear to me on to encode the baud_t information on current termios
> struct. Is the idea to reuse c_ispeed/c_ospeed fields? We might have some
> freedom here since they are not POSIX, but since we set them on
> cfsetospeed/cfsetispeed we will break this semantic if we reuse them.
> 

Yes, the idea is to reuse the c_xspeed fields, but not doing the swap
part (but the floating-point stuff it we need it) since it is not needed.

> 
> This might be an option, it should cover mostly operations. The only issue I
> can see if/when kernel starts to support baud rates over 4 Gbps, will it follow
> the same userland definition or will it use a termios3 struct with larger
> c_*speed values? For latter how would it handle the cases where underlying
> hardware supports a baud rate which is not representable in this 5:27 format,
> would it return EINVAL or round the input?
> 

We already round the input; for example, if you ask a standard PC serial
port for 100000 bps then the value will be rounded to 115200 (divisor of
1), and a subsequent TCGETS2 ioctl will report that speed.

> Another option might be just extend the termios structure to use large values
> for c_ispeed/c_ospeed and add a compatibility symbols for all architectures
> (and no more sparc/mips issues).
> 

From discussing with the kernel team, they aren't particularly
interested, so far, on having to introduce a new kernel interface, but
are willing to reserve the high bits in the speed fields for the future.

        0hpa

-- 
You are receiving this mail because:
You are on the CC list for the bug.