> There are a number of infelicities in the way we currently handle the > I/O plumbing for devices in the kernel. These include: [...]
Thank you. I don't agree with all of that (which I daresay astonishes nobody), but much of it sounds like a codification of some vague unease that's been floating around half-formed in the back of my mind for...well, gradually forming for almost as long as I've been using Unix variants, meaning something like 40 years at this point. There is, however, one thing I think is missing in your rework proposal. I see nowhere to fit in a one-off driver for idiosyncratic hardware - or as a pseudo-device interface to idiosyncratic kernel code. I've personally done enough instances of each that I would find it close to crippling if support for them were to be lost. > For disks, which for historical reasons live in both cdevsw and > bdevsw, both entries would point at the same disk_dev. I would suggest getting rid of the bdev/cdev distinction. It is, as you say, a historical artifact, and IMO it is not serving anyone at this point. > (2) Abolish ioctl inside the kernel, or at least within the device > tree. This would, I think be possibly the hardest part of dealing with idiosyncratic drivers such as I sketched above. Some of the drivers I've done use ioctls, some use I/O on minor sub-numbers (eg, the low three bits of the minor number select a functional interface whereas the rest of the bits are the "true" minor number), but most of them need something of the sort. > A third question: how does this affect interfaces? As in, network interfaces? Good question. I think they should be device nodes in the filesystem *somehow*. For example, at present there is no way to grant someone tcpdump access to le0 without granting tcpdump access to all interfaces, short of a custom setuid program, or something even more contrived such as bridge and a special-purpose tap instance. Seems to me this really should be doable with as little as chown (or chgrp) and chmod, much as it currently is for (say) ttys. I also believe Bluetooth should be just another AF rather than being its own weird mess tacked onto the side of the networking subsystem. I don't know if that's worth taking on, but, given the magnitude of this overhaul, it seems like a good opportunity to fix things like that, or the aforementioned legacy cdev/bdev split. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
