[PATCH] linux/termio: remove <termio.h> and struct termio

[H. Peter Anvin]

On March 31, 2025 11:31:13 AM PDT, "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
>> > 
>> > Let's wait a bit and see what others think about the removal of these
>> > interfaces.
>> 
>> I think we should remove them and clean this up.
>> 
>> If we do it now we have ~4 months of Fedora Rawhide, OpenSUSE Tumbleweed
>> testing to see what breaks.
>> 
>> We won't know until we clean this up and then follow up.
>> 
>
>Actually, (following pointers from other Gentoo toolchain team members and
>poking a bit in git), it looks like musl never had this interface. 
>
>So anything that works there should automatically be fine with the change.
>
>(FWIW, we're also running the test builder with the removal patch now.)
>

So the POSIX committee responded to my ping about the general problem of relying on enumerated constants for <termios.h> and are suggesting that a few implementations (i.e. Unix flavors) get together and come up with a common interface. Andrew Josey, the chair, has put out a call for other implementors that are still doing active development (MacOS? Anyone else, really?) to long me on it.

What I would like to propose is the idea I had a few years ago of a new cf[gs]et[io]baud() and baud_t interface (naming TBD, of course) to replace the existing ones. baud_t would explicitly be a numeric type; it wouldn't necessarily even have to be restricted to an integral type (although in Linux I strongly suggest sticking with the unsigned int that is used by the kernel termios2 interface until someone has a need to represent 5 Gbps...)

It would have the advantage of not requiring mucking with the existing interfaces, avoiding potential problems with speed_t constants being passed across DLL boundaries. 

Adding a new interface as opposed to revving an old one has the benefit of being much easier to infill for old implementations by adding a translation layer – but of course in that case it doesn't provide the new functionality. 

MIPS and SPARC still need a new termios structure, and tc[gs]etattr() still need fixing – this is handled by my WIP.

That being said, there is probably still value in more aggressively deprecating <termio.h>, but that means it doesn't need to be a precondition.

I don't currently have a copyright assignment, as it is a fair bit of paperwork to get one as an Intel employee (in the past I have usually collaborated closely with H.J. so it hasn't been a major problem) but I'm working on it.