On Mon, Nov 19, 2018 at 4:28 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen <tycho@xxxxxxxx> wrote: > > > These tools also care about ioctls. Adding a system call is a pain, > > > but the solution is to make adding system calls less of a pain, not to > > > permanently make the Linux ABI worse. > > > > For user-defined values of "worse" :) > > > > I tend to agree with Tycho here. But I'm wondering if it might be > worth considering a better ioctl. > > /me dons flame-proof hat > > We could do: > > long better_ioctl(int fd, u32 nr, const void *inbuf, size_t inlen, > const void *outbuf, size_t outlen); > > and have a central table in the kernel listing all possible nr values > along with which driver they belong to. We could have a sane > signature and get rid of the nr collision problem. The essential difference between a regular system call and an ioctl is that in the former, the invoked kernel-side code depends on the operation number, and in the latter, the invoked kernel-side code depends on the operation number and file descriptor type. By creating a new kind of collision-free ioctl, all you've done is re-invent the system call, but with a funky calling convention and less operand space. It makes no sense. Previous system call multiplexers --- e.g., socketcall --- are widely regarded as mistakes, and there's no reason to repeat these mistakes. System call numbers are not scarce, and your other proposal to clean up the x86 numbering will make wiring up a new system call less annoying. The *only* purpose of an ioctl is to solve the system call numbering coordination problem --- if the invoked kernel-side code depends on (DRIVER, OPERATION_NUMBER), and DRIVER can vary out-of-tree with ioctl, ioctl lets out-of-tree code expose interfaces. For in-tree code, this problem doesn't exist, so there's no reason to use the awkward ioctl workaround!
