This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] termios: non-standard baudrates are not handled properly on Linux-systems (BZ#10339)

Hi all,

Hans Peter Anvin has summarized the current issues with POSIX termios Linux 
implementation on glibc [1]:

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 
   12 Mbps.

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 
     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.

  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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]