[Bug libc/10339] Terminal interface: non-standard baudrates are not handled properly on Linux-systems

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=10339

--- Comment #9 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
> However, actually, this does not work as described.  cfgetspeed
> returns a traditional B9600 value, not the number 9600 (or whatever).
> (cfsetspeed does accept baud rates in bps as documented and converts
> them to magic constants in the struct termios).

> The only way to make this work as documented in the glibc manual would
> be to change the Bnnnn #defines each to have the value nnnn.  That
> would break compatibility with programs which know about setting
> c_cflags&CBAUD to Bnnnn.  (I think such programs will exist.)

And these programs are not portable if they are setting the speed
by themselves instead of using POSIX defined cf*speed functions.

> I therefore suggest that the specification is wrong.  cfget{i,o}speed
> are defined in POSIX to return these Bnnnn constants, and the values
> of the constants can't be changed, so users of cfget{i,o} speed will
> never be able to expect speeds.  cfgetispeed and cfgetospeed have to
> continue to return magic constants rather than baud rates.

We do have an option to change Bnnn constans, but it in incur in
tradeoffs.  So the options we have are:

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

There were previous cases where we kept binary semantic for old 
binaries, but removed non-conformant usage in favor of POSIX semantic.
However I am not sure if it worth the potential breakage, specially
on API that has not been changed for some time.

Could I bring this up to libc-alpha so we check which other developers 
the best course of action?

-- 
You are receiving this mail because:
You are on the CC list for the bug.