The following issue has been SUBMITTED. ====================================================================== https://www.austingroupbugs.net/view.php?id=1916 ====================================================================== Reported By: hpa Assigned To: ====================================================================== Project: 1003.1(2024)/Issue8 Issue ID: 1916 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: H. Peter Anvin Organization: Linux User Reference: Section: <termios.h>, cf[gs]et[io]speed() Page Number: 441f Line Number: 15334ff Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2025-03-21 22:44 UTC Last Modified: 2025-03-21 22:44 UTC ====================================================================== Summary: termios: the speed_t interfaces are inadequate Description: It should be more than clear at this point that the speed_t interfaces in termios, cf[sg]et[io]speed(), are insufficient for any reasonable serial user. Perhaps the thought at one point was that TIA232 (RS232) would go away, but it lives on (more frequently with logic level than the original PHY) as well as its cousins RS422 and RS485.
The portable list of baud rates is woefully inadequate; in fact, the most common baud rate in use today, 115200, is not on the list. The problems are: 1. There is no portable way to discover at compile time what additional B... constants are on a certain platform. 2. There is no portable way to indicate that a platform supports arbitrary baud rates. Clearly having individual B constants for every possible integer is not feasible. 3. On a single platform, multiple kinds of hardware may be supported, each of which have their own granularity requirements for the baud rate. In general a system call is required to establish the closest available baud rate; it is not something that can be directly done in user space. It is worth noting that the statement of baud (modulation symbols per second) versus bits per second is not necessarily the best way to describe the issue. For a modem, the baud rate may indeed be substantially different from the bit rate, but if one takes the point of view that the tty interface implements or emulates a TIA232 connection, then arguably "baud" more correct than "bits per second", as TIA232 uses between n+2 and n+4 symbols to encode n bits of information. For that reason, I believe there is no fundamental reason not to use the term "baud", and I have done so below. Desired Action: I brought this up in the context of glibc, but the glibc maintainers noted that since this is fundamentally a portability issue, that it would be better dealt with in this group. I see a few options for addressing this, in more or less my personal order of preference: 1. The simplest option: add a test macro to <termios.h> e.g. _POSIX_TERMIOS_SPEED_IS_BAUD which, if defined and set to 1, means that software can ignore the B... constants and treat speed_t as a numeric type, i.e. Bxxx == xxx for all xxx. The case of B constants being arbitrary is deprecated. 2. New get/set interfaces which take a numeric type, and optionally an associated numeric type, suggested to be cf[gs]et[io]baud() and baud_t, but still operate "offline" on a struct termios using tcgetattr/tcsetattr. 3. New interfaces that convert between speed_t and a numeric type (e.g. cfbaudtospeed(), cfspeedtobaud()). This means that the number of baud rates than can be supported is still limited to (1 << sizeof(speed_t))-1; for some existing implementations that will be a 16-bit number. All of these of these options means that an application can only find the true baud rate after setting it (tcsetattr, tcgetattr). An online (system call) interface to convert between a desired and resulting baud rate for a particular interface (file descriptor) could be provided, of course, and could be combined with either of the above. This is a relatively heavy implementation burden, though, as it typically will touch individual device drivers. As such, there must realistically be a way for such an interface to gracefully fail and require that software falls back to the set-get method. Note that it is already the case that "not all baud rates need to be supported by the underlying hardware", and so this is not a new problem. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2025-03-21 22:44 hpa New Issue ======================================================================
