[PATCH] Linux: Define struct termios2 and its ioctls on all architectures

H. Peter Anvin hpa@zytor.com
Wed Jul 9 00:59:50 GMT 2025


On 2025-07-04 12:44, Florian Weimer wrote:
>>
>> It is, though, and as a result the termios 1 ioctls don't work. In
>> general I think it is better to discourage anyone from using the
>> ioctls at all.
> 
> The patch does that, by undefining the termios 1 ioctls.
> 
> Should we undefined the termios 2 ioctls, too?
> 

Here is my concern with all of this:

We are not dealing with a clean slate here. We have 17 years of ad hoc 
workarounds in the field, and the more we change at once, the more we 
risk breaking those.  As such, I would suggest we defer any 
optimizations to 2.43, or if

I'm also not super keen on the idea of filtering ioctls in user space, 
as that is a cost that is borne by every single ioctl user, even if it 
is rather small.  Perhaps more importantly, the general expectation that 
ioctl() is a direct kernel interface is pretty universal.

Now, that being said, I would strongly like to get rid of the hack of 
specifying the length of an ioctl as an ad hoc array -- for all ioctls. 
There is no reason not to define the corresponding structures in the 
__kernel_ namespace instead of using a fully opaque type.

Again, I would like to clean up the uapi headers in the kernel to be 
nicer in this way, but that's another task entirely...

	-hpa



More information about the Libc-alpha mailing list