re: Devices.
Brian Buhrow writes: > hello David. What I don't see in your proposal is a way of > implementing a dynamic device > filesystem. NetBSD, and possibly OpenBSD, are the last Unix-like OS's that > I'm aware of that > use static special files in their filesystems to point to devices. If your > proposal was i don't believe this is a correct claim. linux with udev is, at any reasonably high level, the same as netbsd with devpubd. .mrg.
Re: Devices.
At Tue, 1 Jun 2021 14:00:50 -0400 (EDT), Mouse wrote: Subject: Re: Devices. > > Uh, maybe _you_ do. _I_ don't. For most of my chroots, I want the > chroot to have as minimal a set of devices as still allows it to do its > job, and in particular I do not want it to ever dynamically acquire new > devices, nor do I want it to have /dev entries for devices not > necessary for its task. I not infrequently want unusual ownerships or > permissions on its /dev, too. Indeed. Very important! > I also want to be able to have device nodes places other than /dev, and > that desire is at least mostly orthogonal to chroot. I'm less convinced of this part though This ability has brought more complexity (e.g. mount options to disable devices per filesystem) than I've ever seen pay off in benefit. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgp8ynnPwmB1n.pgp Description: OpenPGP Digital Signature
Re: Devices.
At Sat, 29 May 2021 16:17:13 -0700, John Nemeth wrote: Subject: Re: Devices. > > 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. I'm uncomfortable with what seems to me to be a rather arbitrary decision to remove block devices from NetBSD. My understanding w.r.t. the rationale FreeBSD used in deciding to remove the block devices was that FreeBSD never really buffered/cached by device in the first place. Also, according to PHK in his 2002 BSDCan paper about FreeBSD's /dev, "In FreeBSD block devices were not even implemented in a fashion which would be of any use, since any write errors would never be reported to the writing process."[*] [*] https://www.usenix.org/legacy/events/bsdcon02/full_papers/kamp/kamp_html/index.html If I'm not mistaken that's all different in NetBSD though (except maybe for the error handling issue), or am I mistaken??? Of course on Linux the went the other way and there are no raw devices, and clearly that's turned out to be a bad idea, especially for the needs of some tools such as 'dd' and the underlying drivers which all had to double down and add new non-standard controls just to re-implement "raw" access. > We should really get with the times and create a devfs. I dunno. I think it's a good idea for some classes of devices, but I'm not so sure it has to be a one-size-fits-all singular solution. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgp4sxzsRR_r8.pgp Description: OpenPGP Digital Signature
Re: Devices.
On Sun 30 May 2021 at 19:30:04 -0400, John Franklin wrote: > 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? If I were to design a devfs for this, the resulting device nodes would become a directory tree, for the given case something like sd0-+-cgd0-+-cgd0a-+-pv0-+-lv0 |-lv1 \-lv2 "Somehow" these nodes would be device nodes and directories at the same time. That would be much nicer than having two nodes (with slightly different names), one for the device node and one for the directory. I don't think I've seen a devfs like that; there is a hierarchy in the linux /sys/devices but it is determined by physical hardware attachment. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Devices.
> When you want a device tree in a chroot, you just mount the device > filesystem on that chroot. Uh, maybe _you_ do. _I_ don't. For most of my chroots, I want the chroot to have as minimal a set of devices as still allows it to do its job, and in particular I do not want it to ever dynamically acquire new devices, nor do I want it to have /dev entries for devices not necessary for its task. I not infrequently want unusual ownerships or permissions on its /dev, too. I also want to be able to have device nodes places other than /dev, and that desire is at least mostly orthogonal to chroot. A devfs that could be configured that way, well, maybe. Most of the ones I've seen can't, but I haven't been staying au courant with them. /~\ 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
Re: Devices.
hello David. What I don't see in your proposal is a way of implementing a dynamic device filesystem. NetBSD, and possibly OpenBSD, are the last Unix-like OS's that I'm aware of that use static special files in their filesystems to point to devices. If your proposal was extended with the idea that we have a device filesystem, then wouldn't we only need one implementation of a filesystem that knows anything about devices? When you want a device tree in a chroot, you just mount the device filesystem on that chroot. That filesystem would need a utility that converts a configuration file or database into static permissions and ownership, but that could be done on a per-instance basis, i.e. have a configuration that describes /dev at the root of the system, and other /dev's that describe chrooted dev environments, or dev's in application directories. The only case that doesn't cover, that I'm aware of, is what to do about sockets and fifos, which are commonly scattered all over filesystem trees. In any case, with the advent of gpt named partitions, zfs volumes, USB pluggable devices and other dynamic device environments, not having a dynamic device filesystem is becoming a real detriment. The way we handle ZFS is just goofy and fraught with bugs in dynamic situations.I'd like to see a more integrated approach to this problem. -thanks -Brian
