* Adhemerval Zanella: > On 11/04/2019 08:07, Florian Weimer wrote: >> * Adhemerval Zanella: >> >>> This allows us to adjust the baud rates to non-standard values using termios >>> interfaces without to resorting to add new headers and use a different API >>> (ioctl). >> >> How much symbol versioning will be required for this change? > > I think all interfaces that have termios as input for sparc and mips > (tcgetattr, tcsetattr, cfmakeraw, cfgetispeed, cfgetospeed, cfsetispeed, > cfsetospeed, cfsetspeed). > > Alpha will also need to use termios1 for pre-4.20 kernels. So only new symbol versions there? Hmm. >>> As Peter Anvin has indicated, he create a POC [1] with the aforementioned >>> new interfaces. It has not been rebased against master, more specially against >>> my termios refactor to simplify the multiple architecture header definitions, >>> but I intend to use as a base. >> >> Reference [1] is still missing. 8-( > > Oops... it is https://git.zytor.com/users/hpa/glibc/termbaud.git/log/?h=wip.termbaud This doesn't really illuminate things. “Drop explicit baud setting interfaces in favor of cfenc|decspeed()” removes the new symbol version for the cf* functions. My gut feeling is that it's safer to add new interfaces, based on the actual kernel/userspace interface, rather than trying to fix up existing interfaces with symbol versioning. The main reason is that code involving serial interfaces is difficult to test, so it will take years until we find the last application broken by the glibc interface bump. I don't feel strongly about this. This came out of a request for enabling TCGETS2 support downstream. If I can't fix this upstream, I will just reject that request. Thanks, Florian