>> [...devfs config file...]
> This is all pretty convoluted.  Let me phrase the question this way:
> what problem does this solve?

It appears you're asking "what problem does this config file solve?",
but later text makes it clear you're really asking "what problem does
devfs solve?".  You give two answers to that:

> I see two possibilities: it keeps /dev from being cluttered with
> non-existent nodes, and it avoids the necessity of having to create
> nodes when a new device is added.

but you're missing another one - devfs means that nobody outside the
kernel needs to know what major number corresponds to what driver.

> Let me suggest a simpler devfs that will avoid the need for this
> file.

> Indeed have a devfs.  At boot time, though, before anything at
> userlevel is run and before devfs is mounted, each device driver
> verifies that its /dev entries exist.  Any that don't exist -- this
> can be table-driven, with parameters describing what nodes are to be
> created.  That solves the second problem.  The first problem is
> solved by a devfs layer that, before returning any device inode,
> verifies that it exists in the running system.

Right - but now the admin does "chown uucp:uucp /dev/tty02" or
"ln -s lpt1 /dev/scanner".  How do you make the results of such
commands persist across reboots?  That problem is introduced by a devfs
that has no permanent storage backing it, and _that_ is the problem the
config file solves.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B