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

[Florian Weimer]

* H. Peter Anvin:

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

That's possible.

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

So it's more like tcsetattr writing register contents, and tcgetattr
reading it back, but what the device does with it, is up to the device?

And if some application writes register contents, it could mean that
it's not what another application expects and can interpret.

With versioned symbols, glibc can try to reconstitute something that
looks more like what we had before in the compat tcgetattr.  The new
symbol versions could then hopfully can keep rewriting to the minimum,
so that things are more compatible with future kernel development.
Without the versioned symbols, rewriting has to happen in tcsetattr,
for both old and new binaries.