linux/termio: remove <termio.h> and struct termio

  The <termio.h> interface is absolutely ancient: it was obsoleted by
<termios.h> already in the first version of POSIX (1988) and thus
predates the very first version of Linux. Unfortunately, some constant
macros are used both by <termio.h> and <termios.h>; particularly
problematic is the baud rate constants since the termio interface
*requires* that the baud rate is set via an enumeration as part of
c_cflag.

In preparation of revamping the termios interface to support the
arbitrary baud rate capability that the Linux kernel has supported
since 2008, remove <termio.h> in the hope that no one still uses this
archaic interface.

Note that there is no actual code in glibc to support termio: it is
purely an unabstracted ioctl() interface.
---
 sysdeps/unix/sysv/linux/Makefile           |  6 ------
 sysdeps/unix/sysv/linux/bits/ioctl-types.h | 11 -----------
 sysdeps/unix/sysv/linux/termio.h           |  6 ------
 3 files changed, 23 deletions(-)
 delete mode 100644 sysdeps/unix/sysv/linux/termio.h
  

* H. Peter Anvin:

> The <termio.h> interface is absolutely ancient: it was obsoleted by
> <termios.h> already in the first version of POSIX (1988) and thus
> predates the very first version of Linux. Unfortunately, some constant
> macros are used both by <termio.h> and <termios.h>; particularly
> problematic is the baud rate constants since the termio interface
> *requires* that the baud rate is set via an enumeration as part of
> c_cflag.
>
> In preparation of revamping the termios interface to support the
> arbitrary baud rate capability that the Linux kernel has supported
> since 2008, remove <termio.h> in the hope that no one still uses this
> archaic interface.
>
> Note that there is no actual code in glibc to support termio: it is
> purely an unabstracted ioctl() interface.

Do you have copyright assignment with the FSF?  If not, we'd prefer
Signed-off-by: even if it's just deleting code. 8-)  I assume you are
familiar with the DCO terms.

The mechanics look okay to me.  If we want to push this into upstream
now, we'd need a NEWS entry, under “Deprecated and removed features, and
other changes affecting compatibility”.

Let's wait a bit and see what others think about the removal of these
interfaces.

Thanks,
Florian
  

On 3/27/25 6:10 PM, Florian Weimer wrote:
> * H. Peter Anvin:
> 
>> The <termio.h> interface is absolutely ancient: it was obsoleted by
>> <termios.h> already in the first version of POSIX (1988) and thus
>> predates the very first version of Linux. Unfortunately, some constant
>> macros are used both by <termio.h> and <termios.h>; particularly
>> problematic is the baud rate constants since the termio interface
>> *requires* that the baud rate is set via an enumeration as part of
>> c_cflag.
>>
>> In preparation of revamping the termios interface to support the
>> arbitrary baud rate capability that the Linux kernel has supported
>> since 2008, remove <termio.h> in the hope that no one still uses this
>> archaic interface.
>>
>> Note that there is no actual code in glibc to support termio: it is
>> purely an unabstracted ioctl() interface.
> 
> Do you have copyright assignment with the FSF?  If not, we'd prefer
> Signed-off-by: even if it's just deleting code. 8-)  I assume you are
> familiar with the DCO terms.
> 
> The mechanics look okay to me.  If we want to push this into upstream
> now, we'd need a NEWS entry, under “Deprecated and removed features, and
> other changes affecting compatibility”.
> 
> 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.
  

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

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.
  

On 3/27/25 15:10, Florian Weimer wrote:
> * H. Peter Anvin:
> 
>> The <termio.h> interface is absolutely ancient: it was obsoleted by
>> <termios.h> already in the first version of POSIX (1988) and thus
>> predates the very first version of Linux. Unfortunately, some constant
>> macros are used both by <termio.h> and <termios.h>; particularly
>> problematic is the baud rate constants since the termio interface
>> *requires* that the baud rate is set via an enumeration as part of
>> c_cflag.
>>
>> In preparation of revamping the termios interface to support the
>> arbitrary baud rate capability that the Linux kernel has supported
>> since 2008, remove <termio.h> in the hope that no one still uses this
>> archaic interface.
>>
>> Note that there is no actual code in glibc to support termio: it is
>> purely an unabstracted ioctl() interface.
> 
> Do you have copyright assignment with the FSF?  If not, we'd prefer
> Signed-off-by: even if it's just deleting code. 8-)  I assume you are
> familiar with the DCO terms.
> 
> The mechanics look okay to me.  If we want to push this into upstream
> now, we'd need a NEWS entry, under “Deprecated and removed features, and
> other changes affecting compatibility”.
> 
> Let's wait a bit and see what others think about the removal of these
> interfaces.
> 

Here is a patch with the Sob tag and the NEWS entry.

	-hpa
  

There are more definitions in
sysdeps/unix/sysv/linux/mips/bits/ioctl-types.h and
sysdeps/unix/sysv/linux/powerpc/bits/ioctl-types.h.
  

On April 1, 2025 1:08:37 AM PDT, Andreas Schwab <schwab@suse.de> wrote:
>There are more definitions in
>sysdeps/unix/sysv/linux/mips/bits/ioctl-types.h and
>sysdeps/unix/sysv/linux/powerpc/bits/ioctl-types.h.
>

Ah yes, of course :)
  

Here is an updated patch which removes those as well.

	-hpa


On 4/1/25 01:08, Andreas Schwab wrote:
> There are more definitions in
> sysdeps/unix/sysv/linux/mips/bits/ioctl-types.h and
> sysdeps/unix/sysv/linux/powerpc/bits/ioctl-types.h.
>
  

* H. Peter Anvin:

> From 4f1027fcc979366db3a5c8d2072456ce43bca522 Mon Sep 17 00:00:00 2001
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: Thu, 27 Mar 2025 13:47:10 -0700
> Subject: [PATCH] linux/termio: remove <termio.h> and struct termio
>
> The <termio.h> interface is absolutely ancient: it was obsoleted by
> <termios.h> already in the first version of POSIX (1988) and thus
> predates the very first version of Linux. Unfortunately, some constant
> macros are used both by <termio.h> and <termios.h>; particularly
> problematic is the baud rate constants since the termio interface
> *requires* that the baud rate is set via an enumeration as part of
> c_cflag.
>
> In preparation of revamping the termios interface to support the
> arbitrary baud rate capability that the Linux kernel has supported
> since 2008, remove <termio.h> in the hope that no one still uses this
> archaic interface.
>
> Note that there is no actual code in glibc to support termio: it is
> purely an unabstracted ioctl() interface.
>
> Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
> ---
>  NEWS                                       |  5 ++++-
>  sysdeps/unix/sysv/linux/Makefile           |  6 ------
>  sysdeps/unix/sysv/linux/bits/ioctl-types.h | 11 -----------
>  sysdeps/unix/sysv/linux/termio.h           |  6 ------
>  4 files changed, 4 insertions(+), 24 deletions(-)
>  delete mode 100644 sysdeps/unix/sysv/linux/termio.h

I'm inclined towards merging this.

Any objections?

Thanks,
Florian
  

On April 9, 2025 9:58:59 PM PDT, Florian Weimer <fweimer@redhat.com> wrote:
>* H. Peter Anvin:
>
>> From 4f1027fcc979366db3a5c8d2072456ce43bca522 Mon Sep 17 00:00:00 2001
>> From: "H. Peter Anvin" <hpa@zytor.com>
>> Date: Thu, 27 Mar 2025 13:47:10 -0700
>> Subject: [PATCH] linux/termio: remove <termio.h> and struct termio
>>
>> The <termio.h> interface is absolutely ancient: it was obsoleted by
>> <termios.h> already in the first version of POSIX (1988) and thus
>> predates the very first version of Linux. Unfortunately, some constant
>> macros are used both by <termio.h> and <termios.h>; particularly
>> problematic is the baud rate constants since the termio interface
>> *requires* that the baud rate is set via an enumeration as part of
>> c_cflag.
>>
>> In preparation of revamping the termios interface to support the
>> arbitrary baud rate capability that the Linux kernel has supported
>> since 2008, remove <termio.h> in the hope that no one still uses this
>> archaic interface.
>>
>> Note that there is no actual code in glibc to support termio: it is
>> purely an unabstracted ioctl() interface.
>>
>> Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
>> ---
>>  NEWS                                       |  5 ++++-
>>  sysdeps/unix/sysv/linux/Makefile           |  6 ------
>>  sysdeps/unix/sysv/linux/bits/ioctl-types.h | 11 -----------
>>  sysdeps/unix/sysv/linux/termio.h           |  6 ------
>>  4 files changed, 4 insertions(+), 24 deletions(-)
>>  delete mode 100644 sysdeps/unix/sysv/linux/termio.h
>
>I'm inclined towards merging this.
>
>Any objections?
>
>Thanks,
>Florian
>

Just please get the updated version.
  

* H. Peter Anvin:

> On April 9, 2025 9:58:59 PM PDT, Florian Weimer <fweimer@redhat.com> wrote:
>>* H. Peter Anvin:
>>
>>> From 4f1027fcc979366db3a5c8d2072456ce43bca522 Mon Sep 17 00:00:00 2001
>>> From: "H. Peter Anvin" <hpa@zytor.com>
>>> Date: Thu, 27 Mar 2025 13:47:10 -0700
>>> Subject: [PATCH] linux/termio: remove <termio.h> and struct termio

>>I'm inclined towards merging this.
>>
>>Any objections?

> Just please get the updated version.

The version you posted ~5 hours ago still carries the March 27 date.  I
assume that's the most recent one?

Thanks,
Florian
  

On April 10, 2025 12:01:44 AM PDT, Florian Weimer <fweimer@redhat.com> wrote:
>* H. Peter Anvin:
>
>> On April 9, 2025 9:58:59 PM PDT, Florian Weimer <fweimer@redhat.com> wrote:
>>>* H. Peter Anvin:
>>>
>>>> From 4f1027fcc979366db3a5c8d2072456ce43bca522 Mon Sep 17 00:00:00 2001
>>>> From: "H. Peter Anvin" <hpa@zytor.com>
>>>> Date: Thu, 27 Mar 2025 13:47:10 -0700
>>>> Subject: [PATCH] linux/termio: remove <termio.h> and struct termio
>
>>>I'm inclined towards merging this.
>>>
>>>Any objections?
>
>> Just please get the updated version.
>
>The version you posted ~5 hours ago still carries the March 27 date.  I
>assume that's the most recent one?
>
>Thanks,
>Florian
>

If it includes the changes to sparc and mips it is the current one.
  

On April 10, 2025 12:01:44 AM PDT, Florian Weimer <fweimer@redhat.com> wrote:
>* H. Peter Anvin:
>
>> On April 9, 2025 9:58:59 PM PDT, Florian Weimer <fweimer@redhat.com> wrote:
>>>* H. Peter Anvin:
>>>
>>>> From 4f1027fcc979366db3a5c8d2072456ce43bca522 Mon Sep 17 00:00:00 2001
>>>> From: "H. Peter Anvin" <hpa@zytor.com>
>>>> Date: Thu, 27 Mar 2025 13:47:10 -0700
>>>> Subject: [PATCH] linux/termio: remove <termio.h> and struct termio
>
>>>I'm inclined towards merging this.
>>>
>>>Any objections?
>
>> Just please get the updated version.
>
>The version you posted ~5 hours ago still carries the March 27 date.  I
>assume that's the most recent one?
>
>Thanks,
>Florian
>

(Otherwise see the git tree link I put in the bug report, which also includes the termios change set on top.)
  

On Apr 10 2025, H. Peter Anvin wrote:

> If it includes the changes to sparc and mips it is the current one.

It doesn't, obviously.
  

On April 10, 2025 12:59:21 AM PDT, Andreas Schwab <schwab@suse.de> wrote:
>On Apr 10 2025, H. Peter Anvin wrote:
>
>> If it includes the changes to sparc and mips it is the current one.
>
>It doesn't, obviously.
>

Ok, get the version in the git tree:

<https://git.zytor.com/linux/glibc.git>

Branch hpa/notermio, patch:

<https://git.zytor.com/linux/glibc.git/patch/?id=b69ca3cec54e0fec2779e3496a84f563ee979d20>