Re: Devices.

[David Holland <dholland-tech%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost