Re: Devices.

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B