> > Well, I see a third possibility - replace MAKEDEV with a program that
> > grovels kmem and pulls out all the info that you'd like to put in a
> > devfs.
> Sounds good to me.  Doesn't make things too win95 like (Hey, I'm the
> Computer, I know better what the user wants!),

Well, if the user wants "/dev/bert" to be the name of his root disk drive,
and to work even though it's marked as device 10,0 even though he's just booted
a kernel where the device table says his controller should be represented as
4,0, then the user has rocks in his head.  And let us recall that this is
the problem to be solved, booting a kernel with different device numbers
than the previous kernel.  (There's also the problem of the distributed MAKEDEV
script getting out of sync, which is sort of a special case of this.)

This doesn't tend to happen very often when the device table is static, as
in NetBSD, but apparently it happens often enough that people complain about
it.  Rebuilding /dev every boot is certainly overkill, but it certainly
solves the problem of device numbers changing without requiring the installer
to take any action.  (Of course, if the user still wishes to call the root
device "/dev/bert", this solution doesn't help him.  Said user may well be
beyond help.)

[Note:  if the reader tends to respond to new design ideas with "that's not
how we did it when computers ran on STEAM!", just skip the next two
paragraphs.  Note that I will confess to that reaction on more than one
occasion.]

(One potential solution, of course, is to abandon device numbers entirely
and instead pass the entryname down into the open routine; a lot of work,
but it eliminates the table-version skew problem.  Of course, then you *can't*
call your root device /dev/bert (perhaps you can if it's a symlink, since the
extracted "real" name of the device would be available).  This also gets
rid of the problem of being unable to increase the number of partitions on
a disk drive owing to the minor device bit partitioning scheme.

If you think that's a hack, it gets worse:  when I was at MIT, the V7 CHAOSNET
implementation special cased namei to not merely make the entryname available
to the driver, but to be willing to *stop* parsing a pathname in the middle if
it hit a suitable driver, passing the entire rest of the pathname into the
open routine; thus you could open a telnet connection with
"/dev/chaos/223/TELNET" (approximately; this was 18 years ago, and I'm doing
this from memory).  While you may think it grotesque to have parsing routines
in the kernel (well, OTHER parsing routines besides namei), the ability to
create simple network tools with "cat" was a wonder.  [I then borrowed that
idea for UNOS, and even managed to preserve it after rearchitecting the
filesystem code to implement a vnode layer.] )

The idea given at the top of the message (a program that extracts up-to-date
device information from the kernel) doesn't quite solve the old-device-file
problem, but at least it makes a solution available; an UPDATEDEV program
could potentially take that extracted information and then go looking in /dev
for standard-named device files, noting their existing device numbers and
changing them appropriately, and could then look for non-standard device files
in /dev and attempt to make suitable repairs (thus, if "/dev/bert" is a
genuine device node with device number 10/0, UPDATEDEV could potentially infer
from the fact that /dev/sd0a is also 10/0 even though "the a partition of the
first SCSI disk on the first SCSI controller" is now 4/0 that /dev/bert should
be changed to 4/0 as well.  (It would probably be best for UPDATEDEV to either
ask for confirmation before making that change; it's also a trick that only
works once, unless it makes *no* changes unless *all* changes are approved.
Establishing a universally acceptable user interface to this looks
problematic.)  Hmm, if the code for version string checking in kvm_mkdb
worked, it could be borrowed to put a version string on the device table. ;-)

> is compatible with the
> way NetBSD works now, doesn't force the user to use the new way,

It occurred to me that even with the simple autoconstructed /dev/ scheme,
you still have an easy way out:  build your own /dev/ filesystem in a disk
file (with the vnode driver), and then modify /etc/rc to mount your
customized /dev/ over the constructed /dev/.  This *does* rely on the
autoconstructed /dev/ containing a correct /dev/vnd0a, of course -- but
it *will*, that's the whole point.  (You'd also want to modify the script
that shuts down to single-user not to unmount it; perhaps it would be
useful in general to have a mount flag that tells umount -a not to unmount
a filesystem?  (Or that would tell a lenient umount -A not to.))