On Mon, Jun 28, 2021 at 02:35:24PM -0500, Rob Landley wrote: > > Let me see if I understand: > > 1) The API the kernel exports is not what the kernel is doing. > 2) Userspace can't reliably use the API the way it's currently exported. > 3) Even other kernel devs "didn't understand" it. > 4) Fixing it would involve scare quotes and result from a pearl clutching fit. > > ... no, I'm pretty sure I don't understand. > > *shrug* I've cc'd Michael Kerrisk in hopes he can update the man pages. "man > ioctl_list" already documents these ioctls correctishly (modulo the > signed/unsigned part) but might benefit from some sort of "warning, do not trust > the kernel headers here, they are wrong" comment. The philosophical question is whether the encoding of _IO* is actually part of an exported "API", or just a way of encoding codepoints such that when data structures change size, the codepoint automatically changes/breaks. We have historically speaking, a non-trivial number of ioctl's which don't follow the _IO[RW] convention. For example, most of the block ioctls predate the _IO[RW] convention, and they set or get memory without specifying the size of the type that is set or get. Oh, noos! The kernel is (clutchign pearls) *violating* an API "promise". (Although, in reality, these code points existed for long before we imposed this _IO[RW] "API".) Should we break userspace to "fix" this supposed API violation? Or should we go through a huge amount of effort to fix them all? At one point, I had made an attempt to define the "correct" codepoint via a definition of EXT4_IOC_GETVERSION and EXT4_IOC_GETVERSION_OLD, so the kernel would support the "correct" and "wrong" ioctl codepoint. Unfortunate, this got broken when other folks tried to unify everything to use FS_IOC_GETVERSION defined in include/uapi/linux/fs.h. And given that we would have to support the "wrong" codepoint for a decade or more, personally, I've stopped caring about it, especially since we've lived with it for a decade or more, and very few people been harmed. If someone wants to fix up all of the ioctl code points, perhaps so it would make life easier for strace, or some such, it's not a *terrible* idea. (At the very least, it's more useful than KPI-hacking folks submitting whitespace fixes that don't even fix all of the checkpatch.pl "violations".) But forcing all of the ioctl codepoints into the procrustean bed of the _IO[RW] covention is a huge amount of work, and would take years before userspace could depend on this "API". Cheers, - Ted
