On Sun, May 30, 2021 at 12:00:16AM +0200, Johnny Billquist wrote: > On 2021-05-29 22:26, David Holland wrote: > > There are a number of infelicities in the way we currently handle the > > I/O plumbing for devices in the kernel. These include: > > [...] > > Just looking/thinking about the ioctl part - you say abolish it inside the > kernel. So does that mean that we keep the ioctl() interface for user > programs, but we'd create a system function that will translate ioctl() > calls from user programs to different function calls based on class and > function.
Yes, that's the idea. Getting rid of it at the system call interface is a much harder problem (between compat, binary emulation, standards, masses of existing 3rd-party code that calls ioctl explicitly, etc.) and probably not worth biting off at all, let alone right now. (Hopefully this also addresses Paul's email.) This was all based on the experience of adding discard and adding the dispatching for it as a first-class [bc]devsw op rather than an ioctl: it was a pain because it ultimately required touching _every_ driver, not just the ones that needed to support it, but it was far less of a mess than plumbing it as an ioctl would have been. > Which means any time anyone wants to add some new kind of function to a > device, you'd have to adjust the ioctl() system call, the class, all > devices of that class, and of course your specific driver which you want to > do something with the hardware. That is correct; but normally when you do that (like with discard) you want it to exist on every device of that class, even if to begin with most of the implementations are "return ENOSYS". It is unlikely that ioctl can actually be made to go away entirely within the kernel or even the vnode side of the kernel (the networking code is also full of ioctls that this set of plumbing changes would not affect at all) so there'd probably still be a place to stick really ad hoc things. But mostly it's better to avoid those, especially because they gradually accrete into standard interfaces. :-| Note that even if it does become possible to kill off ioctl at the driver level it's not going to happen anytime soon, and that there will also likely need to be some kind of "misc" driver class as well. I would expect the process of moving in this direction to begin by carving off obvious device classes (e.g. disks, audio) and then migrating their ioctls; at some point we'll get to a stage where the stuff that's left is all atypical and it becomes a waste of time to try to make up a framework that fits it all. ... something I should have mentioned in the original mail: centralizing ioctl dispatch also allows having a single copy of any processing code for the arguments, which isn't a big deal for ordinary ioctls but should definitely help with robustness as soon as there are pointers involved or compat32 issues. -- David A. Holland dholl...@netbsd.org
