> This is a big part of what I don't understand: what kind of shop
> that can't even configure and compile a new kernel (a relatively
> trivial task) is going to care about these sorts of things anyway?

I think there are many technically weak 24/7 shops where even the hired
sysadmins don't trust the notion of rebuilding kernels in the field. And
even if they do, once HP or IBM sells management on the idea of boot-time
reconfig without kernel rebuilds, pea-brain management will easily be
convinced that it is "safer" and "faster" and once they spend the money
for it, the sysadmins don't have much choice.

All the more reason why we should _not_ make NetBSD too dependent on such
a scheme.

The analyses by Curt et al. have me quite convinced that any scheme where
we try to statically allocate loads of device minor or major numbers is a
long-term lose. It would be like stubbornly using "char path[MAX_PATH_LEN]"
when we should be using strdup().

If we want device names that don't move, then the best we can do is to have
the kernel build a devfs based on the locator information:

/devfs/mainbus/pci@bus0/pcib@dev7function0/isa@pcib/wdc@port0x1f0/wd@drive0

I could transition slowly from kernel config files to symlink nests, by
teaching config to leave "wd0" alone, so I could symlink /dev/wd0 to the
above path. (Note: I am ignoring wd0[a-h] names for simplicity.)

Probably I would want an rc.devs script to run at boot time, and enforce
the rules that previously were in my kernel config file:

ln -s /devfs/blahblahblah/wd@drive0 /dev/wd0
ln -s /devfs/blahblahblah/wd@drive1 /dev/wd1
create_wd_star_from /dev/wd2	# shell function to build /dev/wd2 on up

Alternatively there could be a generic script that respected previously
existing symlinks, but added new symlinks for devices that didn't have one
already. This would allow emulation of the solaris "boot -r" operation,
but would not be as misleadingly easy to invoke. You'd have to make clean
in /dev before running the script. This still needs some thought, but I
prefer a solution that encourages people to have backups. It is rather nice
that /dev/MAKEDEV exists to recreate any devices we accidentally destroy.

Of course I would need a pre-existing /dev/rootdisk symlink to have been
put in place by sysinst, or perhaps the /devfs pathname could be burnt into
the bootblocks for that disk. This provides an advantage of its own; on
i386 we would no longer care which BIOS device number was used to boot us.

BUGS

We can only be as stable as the underlying bus address assignments are.
SCAM or isapnp would still cause problems, but only for those devices.

Moving the address of a boot disk that had been "wired down" would
require boot-time recovery and/or procedures to change the wiring.
An option to the boot prompt to pass a /devfs path to the kernel would
be sufficient. Install floppies could also be used to re-wire boot disks
in the event that the /devfs information was not written down anywhere.

Todd Whitesel
toddpw @ best.com