Hi, everybody.  Remember me?  I'm the guy who started this whole
thread, with something incredibly relevant to cWtXdYsZ naming: SCSI
media changers.  :)

Reading this thread has been kind of an exercise in frustration,
because it seems that people are repeating the same things quite a
bit.  Let me see if I can sum up, and maybe lower the noise level a
percent or two.  I'm going to quote lots of people's ideas without
attributing them; interested parties can read the archives:

general comment:  Many people have been making statements to the
effect of, "Purple is the only valid color for shoelaces."  I think
discussion might flow more smoothly if we all were willing to say,
instead, "I really think NetBSD should have purple shoelaces, because
that's the color that's best for me, and for many other folks."  It's
a little bit more wordy, but it's quite a bit more accurate, too.

cWtXdYsZ naming:  Nobody thinks it's a bad idea to have this (and some
people think it's the Right thing), but lots of people think it's a
bad idea to get rid of sdNa style naming.

It would be nice to have a simple system for assigning controller
numbers, and thereby scsibus numbers, in a predictable and transparent
fashion, but the wonderful world of hardware just isn't that nice.

devfs:  Nobody thinks this is a bad idea, either, but nobody has the
time or inclination to implement it just now.  Sounds like a major
project.

run-time reconfig:  (referring to changing device settings like IRQs
without recomiling the kernel)  Again, nobody things this would be a
bad thing.  But nobody's come up with a good, clean way to implement
it.


Now, of course, I have to add my own opinions and suggestions to the
debate.  It doesn't look like any of this stuff is going to happen
soon, which is fine, as long as it gets done correctly (if it gets
done).  That's why lots of us use NetBSD.

Why not write a devfs first, and then make cWtXdYsZ naming on top of
that?  We could, for example, have a userspace program which would be
run from rc after the "mount -u -o rw /", which would make bunches of
soft links from /dev/dsk/* to /dev/sd* or /dev/wd*.  So your root
device can't use cWtXdYsZ naming, but all the rest can.  If (when) we
someday support connecting new devices to a running system, you can
just run the program again.  Or the kernel can send a message on an
appropriate socket, and the daemon on the other end of the socket can
rebuild the soft-link devices.  Whatever; that's a long ways off.

The other piece of this picture would be run-time reconfig.  It would
allow you to assure that scsibuses were attaching to the correct
corresponding controllers; you could run the reconfig thing (boot
option?) whenever you change hardware, make sure devices haven't
magically moved around, and continue booting.

Random idea:  Could the reconfig process tweak variables in the
on-disk binary of the kernel?  Kind of like using adb on a binary?
This wouldn't preserve configuration changes across kernel changes,
but it would eliminate dependency on a config file on your root disk.
Neither option seems pretty to me, though; and, on further reflection,
this option seems very unappealing.

Anyway, I hope all of this review hasn't been really obvious to
everybody else, but I felt like I kind of needed it to keep track of
what's been decided and what hasn't.

Chris

-- 
-----------------------------------------------------cjones@math.montana.edu
Chris Jones                                          cjones@honors.montana.edu
           Mad scientist at large                    cjones@nervana.montana.edu
"Is this going to be a stand-up programming session, sir, or another bug hunt?"