Re: Devices.

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

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
dholland%netbsd.org@localhost