The need for tcsetattr@GLIBC_2.42.1 and tcgetattr@GLIBC_2.42.1

[H. Peter Anvin]

On 2025-09-15 02:07, H. Peter Anvin wrote:
> On 2025-09-15 01:41, Florian Weimer wrote:
>> I think we need symbol version to restrict the new tcsetattr and
>> tcgetattre behavior to newly linked applications.  This would achieve
>> near-perfect backwards compatibility with existing applications (but
>> not those that use dlsym).  I assume this include various industrial
>> control software that can't be recompiled.
> 
> I think you are fundamentally misunderstanding the nature of the recent
> incompatibilities.
> 
> They are CROSS APPLICATION incompatibilities.
> 
> Basically, a broken application goes and modifies only part of the
> kernel state, and expect it to work, based on what kernel state older
> versions of glibc and *MOST* other applications simply didn't know about.
> 
> I fail to see any meaningful scenario that would gain from versioning
> tcsetattr(), and literally no scenario at all that would gain from
> versioning tcgetattr().

Now...

The good news is that the patch I recently posted should provide "near
perfect" backwards compatibility in the case where the user is not using
split speed (i.e. ispeed == ospeed), and it doesn't even require any
application recompilation.

When someone *has* been using split speed, software which does
"c_cflag &= ~CBAUD" is already broken, before or after; it has just been
harder to enable split speed since glibc simply has ignored it
(cfsetispeed() has for most practical purposes been a noop.)

What we can't really do *anything* about is someone picking up Bxxx
constants from <termios.h> and feeding them to ioctl(). Fortunately(!)
the incompatibility between glibc <termios.h> and <linux/termios.h>
actually does make that less likely, but since those are just plain
integers there isn't anything we can do to guard against it across
compilation units; there isn't anything to version there.

	-hpa