Re: Devices.

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

On Sat, May 29, 2021 at 05:41:38PM -0400, Mouse wrote:
 > 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.

It's unlikely to be possible to avoid having a device class called
"miscellaneous" that such things could be stuffed into, because, as
you note, they exist.

 > > 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.

It is deeply baked into the system call API and into POSIX, so it's
not going anywhere. It's been proposed that we should stop having
block devices, which would have the same net effect; I have no strong
opinion on that and it doesn't need to be part of this set of changes.

 > > (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.

Getting rid of it altogether is likely too optimistic for reality. See
next email (upcoming).

 > > 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*.

That's probably true, but they currently aren't and the plumbing above
them is unrelated to the VFS device plumbing, so for the time being
it's a separate issue.

Disentangling the current situation with device special files on
filesystems will make it easier to manifest interfaces on disk if we
ultimately want that.

-- 
David A. Holland
dholland%netbsd.org@localhost