termio support (was: Trying again for termios sanity on Linux)

[H. Peter Anvin]

On 3/21/25 15:55, H. Peter Anvin wrote:
> On 3/21/25 15:12, Florian Weimer wrote:
>> * H. Peter Anvin:
>>
>>> What isn't clear to me is how to handle legacy structures and macros
>>> (in this case the Bnnn macros) in the header files. Are they supposed
>>> to contain some kind of #ifdefs, or is the user simply expected to
>>> compile against an older version of glibc (headers and .so files) if
>>> they want backwards compatibility?
>>
>> Our development model requires the use of an old glibc (for compilation
>> *and* linking) if an application needs to run on earlier glibc version.
>> People have devised various hacks to avoid this, but they are not part
>> of glibc upstream.
>>
>> Technically, we also require recompilation of static libraries against
>> current headers, but we have made some carve-outs in the past.  Symbol
>> versioning does not apply to static libraries because there is no
>> linking step that binds the glibc symbol versions at compilation time of
>> the static library, so linking older libraries incorrectly picks the
>> newest symbol version.  My hunch is that doesn't matter here because use
>> of termios facilities is somewhat rare.
>>
> 
> Especially so since it has been broken for so long :)
> 
> That makes it easy enough.
>

The one issue I'm running into is that the B... constants are shared 
with termio. Is there any sane reason whatsoever to support termio at 
all? The easiest way to deal with it would seem to remove <termio.h> 
entirely.

Otherwise the B... constants would have to be different depending on 
whether <termio.h> or <termios.h> are included.

	-hpa