This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] termios: non-standard baudrates are not handled properly on Linux-systems (BZ#10339)
On 03/10/2018 19:14, H. Peter Anvin wrote:
> On 10/03/18 12:47, Adhemerval Zanella wrote:
>>
>> As I replied, potentially program breakage is unacceptable so I see current two
>> possible way to fix it:
>>
>> 1. Change Bnnn constants on Linux to match termios2 expected values, add
>> compatibility symbols for old semantic, and implement new termios
>> functions based on termios2 kernel abi. cf*speed might accept arbitrary
>> values and we can accommodate new POSIX Bnnn value by mapping directly its
>> integer value.
>>
>> The drawback is potentially breakage of non-compliant programs which set
>> the speed direct on termios instead of using POSIX cf*speed API.
>>
>
> Well, the problem is also if an old application passes an old speed_t
> value to the new API functions or gets one back. This problem can be
> minimized, if not completely eliminated, by symbol versioning.
>
> The direct mucking with c_cflags will actually "just continue" to work
> for existing binary applications. For future *source* applications, this
> should be (mostly) preventable by not exporting the CBAUD and CBAUDEX
> constants to userspace.
>
> None of this, of course, solves the problem of letting the programmer
> assert, in a portable application, that "no, really, the baud rate
> functions take arbitrary integers." In one of my own projects I ended
> up building a really ugly autoconf test for it.
The Bnnn change to match integer values has the advantage of one can
infer speed_t can represent any integer value of the range is typedef.
And possible future POSIX Bxxx additions won't require to change
previous defined values. Portable applications will need to rely on
POSIX Bxxx though.
>
>> 2. Implement a new API to return the line speed in the termios as bits per
>> second, and implement termios functions based on Linux termios2 kernel ABI.
>> Bxxx functions will continue to have legacy values, not breaking non-portable
>> application which may rely on it.
>>
>> The drawback is would be initially a GNU extension (so another glibc
>> idiosyncrasy) and it might conflict with possible POSIX extension if it
>> where proposed for inclusion.
>>
>> 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.
>>
>> Initially I was trying to avoid adding a glibc specific implementation, but
>> after reading the bug reports I am more inclined that the new ABI, along with
>> refactor Linux termios implementation to use termios2 kernel abi, and working
>> to add this on POSIX.
>>
>> Any thoughts about it?
>>
>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=10339
>> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683826
>>
>
> Standardization does have a chicken-and-egg problem, but there is always
> the option to query the POSIX committee. FreeBSD and Windows(!) already
> define their symbolic constants as just the corresponding integer.
>
> One of the nice things about having an entirely new entrypoint is that
> legacy implementations can be wrapped in an extremely simple library
> (which, of course, doesn't address the limited functionality, but there
> is no solving that problem.) Producing that library isn't possible in a
> strictly conforming portable manner, but can in practice be done easily
> enough.
>
> Here is a simple tool which can create such a wrapper, making use of
> "gcc -E -Wp,-dM" to find the macros:
>
> https://www.zytor.com/~hpa/termbps/termbps.tar.gz
>
> -hpa
>