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

[H. Peter Anvin]

On September 22, 2025 4:26:30 AM PDT, Florian Weimer <fw@deneb.enyo.de> wrote:
>* 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.

Unless you have a specific, concrete proposal for what you would like to do, this doesn't really make much sense to discuss in the abstract.

My analysis is that *regardless* of how we do the normalization, it is a detail between glibc and the kernel; introducing a new application-glibc interface which is what you are proposing solves exactly nothing.