1
0
mirror of https://sourceware.org/git/glibc.git synced 2025-06-27 00:01:05 +03:00
Files
glibc/sysdeps/unix/sysv/linux/sparc/bits
H. Peter Anvin (Intel) 5cf101a85a linux: implement arbitrary and split speeds in termios
Linux has supported arbitrary speeds and split speeds in the kernel
since 2008 on all platforms except Alpha (fixed in 2020), but glibc
was never updated to match. This is further complicated by POSIX uses
of macros for the cf[gs]et[io]speed interfaces, rather than plain
numbers, as it really ought to have.

On most platforms, the glibc ABI includes the c_[io]speed fields in
struct termios, but they are incorrectly used. On MIPS and SPARC, they
are entirely missing.

For backwards compatibility, the kernel will still use the legacy
speed fields unless they are set to BOTHER, and will use the legacy
output speed as the input speed if the latter is 0 (== B0). However,
the specific encoding used is visible to user space applications,
including ones other than the one running.

- SPARC and MIPS get a new struct termios, and tc[gs]etattr() is
  versioned accordingly. However, the new struct termios is set to be
  a strict extension of the old one, which means that cf* interfaces
  other than the speed-related ones do not need versioning.
- The Bxxx constants are redefined as equivalent to their integer
  values and the legacy Bxxx constants are renamed __Bxxx.
- cf[gs]et[io]speed() and cfsetspeed() are versioned accordingly.
- tcgetattr() and cfset[io]speed() are adjusted to always keep the
  c_[io]speed fields correct (unlike earlier versions), but to
  canonicalize the representation to ALSO configure the legacy fields
  if a valid legacy representation exists.
- tcsetattr(), too, canonicalizes the representation in this way
  before passing it to the kernel, to maximize compatibility with
  older applications/tools.
- The old IBAUD0 hack is removed; it is no longer necessary since
  even the legacy c_cflag baud rate fields have had separate input
  values for a long time.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2025-06-17 09:11:38 -03:00
..