> > 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.
> 
> *Shrug*. Dealing with multiple SCSI controllers and drives in a
> system is not an easy job. Dealing with this properly, especially
> on PC hardware, is a lot more difficult than learning how to build
> a kernel with things wired down. That's why I don't see the point
> of this whole thing: it's an attempt to cater to people who simply
> don't have the ability anyway.

Certainly for IBM,HP,Sun,etc. it is an attempt to cater to those people.
But is that inherently wrong? To me the various implementations are bad
because they make stupid mistakes, but the basic concept is sound. _If_
someone wants the extra freedom that it allows, they must also be aware
of its pitfalls.

Much of my interest in this is because I see many things _beyond_ it. I'd
like a kernel capable of LKM'ing many of its device drivers, so I do not have
to reconfig+reboot when I borrow a new USB device for a few days. When hot
pluggable busses become more popular, I think this will be a key technology.

> > 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....
> 
> This, along with rc files that go and build this stuff on the fly,
> or building with scripts during system operation, sounds like much
> more of a configuration nightmare to me than simply rebuilding a
> kernel file.

You're glossing over the mandatory MAKEDEV step which is occasionally needed.
There's another advantage to /devfs that I don't think has been mentioned
yet; it's easy to fix up /dev when you needed to do a MAKEDEV but didn't.
When was the last time you ran out of pty's? Enabled a PS/2 mouse? etc.

I don't understand why it would be a "configuration nightmare". Compare:

wd0	at wdc0 drive 0
wd1	at wdc0 drive 1
wd*	at wdc? drive ?

vs. the simplest case, a script that regenerates everything on a reboot:

rm -f /dev/wd*
ln -s /devfs/blahblah/wd@drive0 /dev/wd0
ln -s /devfs/blahblah/wd@drive1 /dev/wd1
autoconfig_wd_star	# contains logic to detect and avoid /dev/wd[01]

The two are information-equivalent. The symlink-nest system is operationally
a superset of the config-file system.

Perhaps it would make sense for the /dev directory to be read-only most of
the time, so it's harder to screw yourself by blowing away devices. That
would help avoid mistakes, period.

Todd Whitesel
toddpw @ best.com