On Tue, Jun 01, 2021 at 10:08:55AM -0700, Brian Buhrow wrote: > hello David. What I don't see in your proposal is a way of > implementing a dynamic device filesystem.
As I already posted about once, that's irrelevant to what I'm proposing. A working devfs that can be used in all places where device nodes might be needed would mean that the device vnode apparatus in ffs and every other fs could be removed, yes, but that does not _solve_ the problem that puts it there, it only centralizes it. Meanwhile it addresses none of the other issues. Also, devfs as popularly envisioned remains a bad idea. As I said before, it's an automounter, not a file system, and automounters are accursed. If you (or anyone else) really wants it to happen, I recommend sorting out _in detail_ how to configure it and where (and how) to store the persistent state it needs to remain compatible with expectations. For example, suppose there are two (different) chroots as well as the "real" /dev and someone inserts a USB microphone, with the intent that one of the chroots (which they're using as a sandbox for a popular videoconferencing app) can use it and the other (which is running code that's potentially overtly hostile) cannot. How do you decide the user/group and mode for the new device node in each of the three instances of /dev? In what language do you write the policy that describes what's supposed to happen? And where does the decision logic execute? Where is the policy stored? How do you get it to reload when needed? None of this is trivial. Also decide for certain whether the objects your devfs automounter adds to the namespace are in fact ordinary device special files with hardcoded major/minor numbers (this is a lot simpler, but defeats much of the point) or should be something more flexible, like dynamically generated vnodes that connect directly to device drivers. Unlike most people talking about it (here and elsewhere) I have actually implemented this (in a research system) and my conclusion from that experience was that it was a mistake. I don't propose to waste my time doing it again. > The way we handle ZFS is just goofy As far as I know this is largely or entirely the fault of the ZFS developers for doing their own thing instead of sticking to the established/conventional abstractions for devices and file systems. -- David A. Holland dholl...@netbsd.org