This is the mail archive of the
mailing list for the glibc project.
[RFC] termios: non-standard baudrates are not handled properly on Linux-systems (BZ#10339)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Cc: Rich Felker <dalias at libc dot org>, hpa at zytor dot com
- Date: Wed, 3 Oct 2018 16:47:14 -0300
- Subject: [RFC] termios: non-standard baudrates are not handled properly on Linux-systems (BZ#10339)
Hans Peter Anvin has summarized the current issues with POSIX termios Linux
implementation on glibc :
1. The set of baud rates supported by modern serial port hardware far
outnumbers the number of flags in c_cflags.
2. Those baud rates are actually *used*, especially in applications driven
from a clock with an integral number of MHz. For example, MIDI is
basically a 31,250 bps (1/32 Mbps) serial port with an optoisolator.
Finally, there are those that support extremely high baud rates, like
3. The POSIX interfaces unfortunately failed to abstract baud rate when the
cf*speed interfaces were added.
4. The Linux kernel unfortunately copied System V a bit too closely.
5. glibc, even though it defined speed fields in its struct termios, didn't
do this abstraction either.
6. Linux has supported arbitrary baud rates for *12 years* now; this interface
was added in kernel version 2.6.20. AFAIK all current supported architecture
implements termios2 kernel abi and all future Linux ports are required to
use the new generic ABI definitions.
7. To use this interface, the new ioctl()s TCGETS2/TCSETS2 need to be used
(except on the small number of platforms that already had them), together
with the use of the new kernel struct termios2.
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
The drawback is potentially breakage of non-compliant programs which set
the speed direct on termios instead of using POSIX cf*speed API.
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 , 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?