On Sat, May 29, 2021 at 08:43:00PM -0400, Mouse wrote: > > We should really get with the times and create a devfs. I know that > > there are people that disagree with this (likely including you), but > > the archaic device node system causes a lot of headaches and it's > > time that we joined the 21st century. > > I am not someone who thinks that we, for any value of 'we", should go > with the new simply because it's new. I strongly agree with this. Too much modern "new" stuff is a downgrade from the previous version, or adds complexity without solving a real problem, or tempts you with something shiny while shackling you to a particular vendor or solution. The days of "new and improved" seem to be all but over. I don't think devfs falls into this category. > I'm curious what headaches you think devfs would fix. (I know what > headaches *I* think it would fix. I'm wondering which ones *you* think > are worth bringing it in for.) Even though I didn't start this thread, I'd like to chime in here. Hardware isn't static, and hasn't been for a long time. Hot-pluggable devices are common on all grades of machine, from embedded systems to laptops/desktops to servers to large VM hosts. We add physical storage in the form of USB drives, eSATA disks, iSCSI and FC LUNs. We add logical storage in the form of crypto block devices, LVM LVs, and partition maps. Beyond mass storage, Bluetooth and USB devices can be network adapters, cameras, audio devices (both in and out), and (thanks to USB-C/TB3) even display devices. The device drivers intrinsically know where in the /dev tree they belong, and can instantiate themselves during attach. It shouldn't require running a userland script or daemon to create new devices. Managing hardware and exposing it to the rest of the system is a job for the kernel. System hardware is dynamic and /dev should be dynamic, too. Modern hardware is complicated. For some, like a USB disk, a single physical device may create multiple nodes, one for the raw USB functions under /dev/usb/, and one for the block device itself. Going back to David's original question of defining classes of devices, devices that are multi-classed and need separate device nodes for each class will need to call functions for all applicable classes. The device driver has full knowledge of the device, let it own the complexity. More complex storage (ZFS, LVM) may create canonical nodes and populate a /dev/mapper subdirectory with symlinks of more human friendly names. For matroska devices, automatic population of /dev is more sane if the device drivers do it themselves: Consider, a USB device is inserted... that has a mass storage block device... encrypted with CGD... hosting a partition map... with an LVM PV in one of the partitions... that contains three LVs. How many device nodes are created here? A devfs makes it easier to migrate from node major,minor numbers to device names/IDs, because the device drivers know who they are and create their own devfs device nodes with appropriate names. A devfs may not bother with names and just map device nodes to device structures. Finally, reducing the clutter. A default NetBSD install has nearly 900 device nodes, the majority of which point to nothing on a given system. > The major downside I've seen is that they also render difficult or > impossible a number of clever things that are rarely useful but > borderline essential when they are useful. Most of those things are As with FreeBSD, a devfs should be optional early on, something that is an enabled option in the kernel config, and maybe require an explicit entry in /etc/fstab to mount. Even after devfs goes mainstream, I'd expect mknod(2) to stick around. Specialized installs with limited memory and truly static devices (think: IoT) may want to stick with plain device nodes. > based on devices being "just" filesystem nodes, leading to things such > as the same device appearing more than once in the filesystem > (including places outside /dev), things such as chroot areas with > hand-crafted (and severely cut-down) /dev directories...some of the > devfs variants I've seen don't even support chmod/chown. Should /dev have a MAC or DAC security policy? That's a debate of it's own. Yes, MAC makes it harder to manage. Security = 1 / convenience. As for chroot environments, the kernel has an outside view and can craft a /dev specific for the chroot-jail, per a defined ruleset. > By the time you (re)implement all the filesystem operations that give > /dev much of its power, you're pretty much back where you started, only > with a custom filesystem - with new and different bugs and far less > well tested code - on /dev. Experimental in 10, optional in 11, preferred in 12, default in 13. That's a rather optimistic schedule. It's a critical subsystem and deserves at least that much testing. It may be that devfs takes two or three releases to advance from one level to the next. > But I really don't think doing away with conventional device nodes is > sane yet. Most of the benefits of devfs can be achieved with some kind > of userland interface to the autoconf tree and some userland daemons - > mechanism, not policy. All the devfses I've seen have, in my opinion, > way too much policy wired into them. I'd like to avoid hardwired policy. The devfs instances I've worked with have a reasonably sane default set of rules, and a way to apply additional rules for specific situations. Making devfs a simple set of tools, and leave the complexity to the users of the tools (device drivers, admin defined rulesets) is the better way to go, IMHO. It should follow the "small tools that do one thing and do it well" philosophy. Maintaining the rules in kernel space means they can be applied during attach without jumping out of the kernel or requiring a watcher daemon to notice new devices and make system calls to apply the rules. There will need to be userland tools to manage the rules in the kernel, of course. Those tools, which may include some policy daemons, update the mechanism (rules) in the kernel. > > [...] I think we have enough brain power and enough real world > > examples to be able to not repeat the mistakes of the past. > > Not if we do it to "join[] the 21st century". That's a very wrong > reason to do...well, almost anything technical. Of course not. It would be to: - To provide an API for device drivers to manage their own device nodes, - To allow for auto-discovery/creation of device nodes, - To allow complex devices to own their own complexity, - To provide a sensible default policy for common cases, - With the ability to override for specific use cases, - To (optionally) provide a MAC security policy in /dev, - And reduce the clutter. jf -- John Franklin franklin%elfie.org@localhost
Attachment:
signature.asc
Description: PGP signature