Re: FreeBSD devfs support on NetBSD 5.0

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

On Fri, Jun 19, 2009 at 09:45:40AM +0100, Iain Hibbert wrote:
 > I've heard it said that waiting for perfection means that you will wait
 > forever. Having said that, I agree with Reinoud in that I would prefer a
 > good implementation over just something that works. It is common enough
 > that when something works nobody will bother to make anything better and I
 > like to think that here at NetBSD we strive for good.

Furthermore, past experience elsewhere has shown that a devfs that
"works" is not necessarily the same as one that one wants to adopt in
the long run.

I have some serious structural concerns, based on experience with
other devfses and based on having done at least two implementations
myself in research kernels. [Anyone who wants to examine these mail
me.]

I am not sure how these apply to mjf's devfs -- the last time I talked
to him about this stuff in any detail was quite some time ago. Nor am
I sure how they apply to the FreeBSD devfs as it currently exists; I
haven't looked at it in some time and I'm hoping it's improved since
then. :-)


(1) Adding (external) objects to the file system namespace is
fundamentally a mount operation. No matter how you structure a devfs
or what kind of setup it has, ultimately you end up duplicating a lot
of the mount logic. This promotes bloat; it also leads to various
subtle problems or mistakes (by coders or by sysadmins) when the
semantics of the two kinds of mount operations turn out to be not
quite the same.

It seems to me that it would be better to have one set of mount logic,
and strengthen it as needed to do what we need. (Right now, dumping
every driver with a /dev node into the mount table would make a huge
mess, because the mount table isn't meant to be that big. But that's
not that hard to fix.)

If you follow this to its conclusion the "fs" part of devfs disappears
entirely and /dev can be just another subdirectory on the root volume.
(Or a tmpfs, or possibly even a deadfs...)


(2) Similarly, *automatically* adding device nodes into /dev is
fundamentally a form of automounting. This is true regardless of
whether it's done on device insertion, on demand when a device is
used, or on whatever other triggers.

Automounting is a notoriously troublesome problem in Unix and none of
the existing solutions for file systems (particularly the existing
solutions for automounting on media insertion) are entirely
satisfactory. Before committing to *any* devfs implementation I'd like
to see an analysis of these problems as they pertain to device nodes
and at least a sketch of an argument for why the in-kernel automounter
we're implicitly buying into is not going to end up a horror.

And also... if we're going to buy into a kernel-level automounter, I'd
like it to be able to handle file systems too. Removable media worked
better in the first Mac (nearly 25 years ago now!) than in Unix today.


(3) There are some inherent and fundamental problems with trying to
support both demand-loaded drivers and automatic name insertion into
/dev. In general, you can either load, probe, and attach a driver on
open of a preexisting device node, or you can generate a device node
after probe and attach of a previously loaded driver, but you can't
really do both. (Unless you divide every driver into separate
probe/attach and operational components. Then you can demand-load the
operational parts. But this would be an enormous undertaking.)

Up until a few months ago that wasn't a problem for NetBSD because
there were no particular plans to be demand-loading device drivers.
That's changed. As far as I know, no solution has been proposed, and
I'm not convinced that any useful solution exists.

One possible way is to make a list of every possible openable device
driver and its name, and use that to drive load and probe/attach on
open. However, that's what we already do: the list is called /dev.


(4) Structurally, permissions are (and should be) properties of the
device driver, not of some intermediate devfs object. Some devices
have (or should have) fixed permissions; for example, "chmod 711
/dev/null" serves no purpose but to render the system dysfunctional
and there's no need to allow it at all... let alone go to a lot of
effort to make its effects persistent.

All of the existing devfs solutions I know of that try to make
permission changes transparently persistent do so by creating some
kind of devfs configuration to own the permissions, instead of putting
the permissions where they belong and providing a facility for drivers
to make driver properties persistent.


(5) I still don't like the idea of kernel systems that require a
service daemon. If the daemon dies, or becomes comatose, will the
system wedge? Or will it instead lose changes? If I boot single user,
who starts the daemon? What happens at shutdown, when the daemon
perhaps needs to continue running until after the root FS is
unmounted? These problems are all solvable with enough effort, but it
seems like a lot of pain for the net benefit.

If there are going to be devfs rules -- or persistent device
properties -- perhaps a better approach is to allow loading and saving
them out of the kernel like firewall rules?


And finally, I'm still not entirely clear on what the benefit of a
devfs is supposed to be.

The devfses that I've implemented have allowed eliminating
cdevsw/bdevsw and using purely dynamic device numbers strictly for ID
purposes. This has certain maintenance benefits. However, this isn't
realistically in the short-term picture for a production OS and as far
as I remember none of the production OS devfses that have been
deployed so far have even considered taking this step or adopting it
as a long-term goal.

Without that, it seems like the only benefit is not having to run
MAKEDEV once in a while, and, bluntly, that just does not seem to be
worthwhile.

I feel like there must be something else or it wouldn't be such an
attractive (mis?)feature, but I don't really see what.


Meh, this mail is a lot longer (and took a lot longer to write) than I
intended.

-- 
David A. Holland
dholland%netbsd.org@localhost