[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