Re: Devices.
mueller6...@twc.com ("Thomas Mueller") writes:
>It's a nuisance not to be able to recognize all partitions on a
>GPT-partitioned drive because not enough dk* nodes have been configured.
>FreeBSD even distinguishes between USB or SCSI disks and SATA disks, and
>between GPT partitions and MBR-based partitions: better than Linux in that
>regard.
We don't even use MBR based partitions, that's just compatibility for firwmare.
We also have a "enough dk* nodes" mode but that's disabled by default.
I personally think that all the "we don't do things like system X" claims
are a nuisance.
Re: Devices.
On May 30, 14:24, Michael van Elst wrote:
} mueller6...@twc.com ("Thomas Mueller") writes:
}
} > Where do I find the "enough dk* nodes" mode? Would it be in
} > the kernel config? I never saw it.
}
} You can run devpubd. When a wedge and thus the dk* unit attaches, it
} runs the 01-makedev hook that creates the device node in /dev.
That's not a "mode". It's a clunky userland daemon that tries
to make up for the fact that we don't have a devfs.
}-- End of excerpt from Michael van Elst
Re: Devices.
from Michael van Elst:
> mueller6...@twc.com ("Thomas Mueller") writes:
> >It's a nuisance not to be able to recognize all partitions on a
> >GPT-partitioned drive because not enough dk* nodes have been configured.
> >FreeBSD even distinguishes between USB or SCSI disks and SATA disks, and
> >between GPT
partitions and MBR-based partitions: better than Linux in that regard.
> We don't even use MBR based partitions, that's just compatibility for
> firwmare.
> We also have a "enough dk* nodes" mode but that's disabled by default.
> I personally think that all the "we don't do things like system X" claims
> are a nuisance.
Where do I find the "enough dk* nodes" mode? Would it be in the kernel config?
I never saw it.
Tom
Re: Devices.
mueller6...@twc.com ("Thomas Mueller") writes:
>Where do I find the "enough dk* nodes" mode? Would it be in the kernel
>config? I never saw it.
You can run devpubd. When a wedge and thus the dk* unit attaches, it
runs the 01-makedev hook that creates the device node in /dev.
Re: Devices.
from John Nemeth: > On May 29, 22:52, David Holland wrote: > } On Sat, May 29, 2021 at 05:41:38PM -0400, Mouse wrote: } > } > > 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. > I was thinking the same thing about getting rid of block > devices. The only place they should ever be used is an argument > to mount(2) and mount(2) can be adjusted to use a block device > underneath when it is handed a character device. FreeBSD got rid > of block devices a long time ago. Doing that as a first step is > likely to simplify things to make other things easier. > } > > 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. > 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. Anything done with > devices should be done with idea of a devfs in mind. Yes, devfs > like things have caused a lot of problems on other operating systems, > but I think we have enough brain power and enough real world examples > to be able to not repeat the mistakes of the past. > }-- End of excerpt from David Holland I strongly agree on creating a devfs! I remember the days of static device nodes in Linux and FreeBSD. FreeBSD switched to devfs with v5 and 6; static device nodes became no longer an option. It is nice to be able to run "ls /dev/da*" and see what USB sticks and hard drives are connected. I believe Linux can still use static device nodes, but users generally prefer dynamic device nodes. It's a nuisance not to be able to recognize all partitions on a GPT-partitioned drive because not enough dk* nodes have been configured. FreeBSD even distinguishes between USB or SCSI disks and SATA disks, and between GPT partitions and MBR-based partitions: better than Linux in that regard. OpenBSD still uses static device nodes and looks backward compared to NetBSD and FreeBSD. Tom
Re: Devices.
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. >
Re: Devices.
>> You can run devpubd. When a wedge and thus the dk* unit attaches, >> it runs the 01-makedev hook that creates the device node in /dev. > That's not a "mode". It's a clunky userland daemon that tries to > make up for the fact that we don't have a devfs. Your wording is heavily biased. To bias in the other direction: I take it you'd rather have that policy hardwired into the kernel, where it can't be changed without kernel-hacking expertise and a reboot, and any bug takes down the whole system, rather than in userland, where it can be changed anytime, and bugs just cause that one piece to break? I would rather have the userland version. "Mechanism, not policy." /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
