> That's fair enough. But this Sort of configuration is not something
> I'd use on a production server, which is what Greg appears to be
> making his argument about. On a production server, which doesn't
> change much, I want everything in the kernel and firmly wired down.

Definitely we must support this administration style. Any new method for
configuring device nodes must not interfere with devices that have been
wired in at config time.

While I would like to reduce our dependency on kernel rebuilds, I don't
want it to disappear; even in my longest-term vision the GENERIC kernel is
statically config'd for everything it is likely to find on its motherboard,
and anything that may be needed to access the root disk (not the boot disk,
ahem) -- and the remaining drivers are LKM'd from root.

> Well, not exactly. The config-file system has the advantage that
> once the system is up and running, the device mappings cannot
> change. An accidental re-run of a configuration script or removal
> and incorrect re-making of a link or two can cause problems; these
> hard-to-detect problems don't happen with kernel configs. (A reboot

Actually they _do_ happen with kernel configs, but are much less likely,
because the guy doing the kernel config probably has a clue.

So we really have flat out conflicting interests. And, I'll admit that in
some environments I would not want to allow people to rearrange the devices
on the fly; in particular on a secure system I would not want to even allow
multi-user root to do it, and the best way to do that is to wire 'em down
and make /netbsd and the /dev nodes immutable.

> is pretty easy to detect. :-)) And keep in mind that on the sorts
> of systems these are aimed at you're not talking about a couple of
> wd devices; you're talking about two or three SCSI controllers and
> a dozen or more SCSI disks. That's not the kind of configuration
> information you're likely to remember for very long, especially
> after the server's been running continuiously for a few months..

This doesn't really argue one way or the other, because a tarfile of the
"good" symlinks, or a dev.rc script that regenerates them correctly, is
basically like /etc/fstab in that your system relies on its integrity but
it is not actually part of the kernel file.

Adding the ability to hard-wire certain /etc files into the kernel might
not be so bad, actually. The ability to boot a usable single-user system
with just /netbsd and /bin/sh would be kinda cool.

Todd Whitesel
toddpw @ best.com