On Mon, Nov 19, 2018 at 2:40 PM Tycho Andersen <ty...@tycho.ws> wrote: > Can I just register an objection here that I think using a syscall > just for this is silly?
Yes, you can argue that the bikeshed should be ioctl-colored and not syscall-colored. > My understanding is that the concern is that some code might do: > > unknown_fd = recv_fd(); > ioctl(unknown_fd, SOME_IOCTL, NULL); // where SOME_IOCTL == PROC_FD_KILL > // whoops, unknown_fd was a procfd and we killed a task! > > In my experience when writing fd sending/receiving code, the sender and > receiver are fairly tightly coupled. Has anyone ever actually fixed a > bug where they had an fd that they lost track of what "type" it was > and screwed up like this? It seems completely theoretical to me. Yes, I have fixed bugs of this form. > The ioctl() approach has the benefit of being extensible. The system call table is also extensible. ioctl is for when a given piece of functionality *can't* realistically get its own system call because it's separated from the main kernel somehow. procfs is a core part of the kernel, so we can and should expose interfaces to it using system calls. > Adding a > syscall means that everyone has to do all the boilerplate for each new > pid op in the kernel, arches, libc, strace, etc. 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.
