On Tue, Jun 29, 2021 at 11:24:26AM -0400, Theodore Ts'o wrote: > 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". Why don't we deprecate FS_IOC_[GS]ETFLAGS and tell everyone to use FS[GS]ETXATTR? They use the same code paths and vfs helpers now. --D > > Cheers, > > - Ted
