> > I DO want magic strings for SCSI, however, so my second HD is always sd1
> > and my Zip drive can have sd2 reserved for it when it's not hooked up.
> > (Or zd0, that'd be nice.)
> 
> Would you accept disks by name? Or volume? I know that this may
> not be practical for Zip drives, but I'm thinking more along the
> lines of you naming a disk "Fred". Where I'm coming from on this
> is that in a multiple path Fibre Channel (or SCSI even, for that
> matter) terms like 'sd2' are mostly meaningless, and you have
> to start identifying disks by WorldWideName or something such-
> but that's not a helpful name (/dev/WWN01234768fff627812541?)-
> so would aliased names in user space be useful?

If by aliased name you mean the equivalent of a hard link from 'sd2' to
the 'WWN01234768fff627812541' name buried in a subdirectory, then I'd be
in favor of that. I really do not like /dev clutter, and support the use
of subdirectories in /dev -- if there can be more than one of a given
device then in principle there can be oodles of them.

Another way to put it is that when I care above /dev I am usually on the
console, and probably don't have scrollback. A list of devices that zooms
off the screen is not fun.

Back to the topic at hand: if we're going to support labeling of things,
then the first request I have to make is that it be done from an /etc file
or something that is editable by root without reconfiguring the kernel.

Maybe that is a tall order, but I really hate recompiling the kernel for
simple crap like moving devices around. I used SunOS for many years and
found the default static SCSI target number mappings to be very handy as
long as I didn't need too many disks to be on the same machine at once.

Removables and hot-pluggable things are a different story however. Just
off the top of my head I would look for a device tree dumper that tells
me, for each device:
    - its current device node and the path to it so I know which lines in
	the kernel config file it depends on.
    - type information and strings returned by the device layer, for example:
	SCSI Disk, "Iomega ZIP 100", serial # 1232500012321
    - status information, to help me figure out which one it is if there are
	many similar devices -- a volume name for disklike things, or the
	mouse button state so I can grab a dead mouse, press the button, and
	run the device dumper to figure out which mouse I'm holding.

Next, I would want either an /etc file or some set of utilities to tell the
kernel how to bind a device mapping. For example I would want all SCSI Disks
identified as "Iomega ZIP 100" to be /dev/zd? and maybe I would want the mouse
whose serial number is # 5544939933 to be /dev/usbmouse0.

usbmouse0 at usbhub? serial "5544939933"

This looks like something I've seen in earlier messages.

Thinking back to the USB idea I was originally writing about, it would be
good to have documentation for the scan order of things in general (maybe
this already exists) so that I would know which order my Zip drives would
be numbered based on their SCSI target numbers or something like that.
I guess I want to avoid giving complicated config lines like this:

zd0 at scsibus? target 5 lun ? ident "Iomega ZIP 100"
zd1 at scsibus? target 6 lun ? ident "Iomega ZIP 100"
zd? at scsibus? target ? lun ? ident "Iomega ZIP 100"

Ultimately, it would be very cool to have a configuration tuner disk that
booted up, scanned my system for _all_ devices, and then allowed me to mount
a partition and write out a config file that exactly represents my hardware.
If this were included into the normal config file so I didn't have to patch
the file together before running config, it would be even better. I suppose
this would raise concerns about the "problem devices" whose probes are known
to be dangerous, but I am just still a little irked that my PS/2 mouse was
not recognized by 1.3.2 until after I uncommented the pms0 line in GENERIC
_and_ created a device node for it (XF86Setup didn't bother to tell me the
device node didn't exist, and it took me a while to figure out why my mouse
was so dead).

Todd Whitesel
toddpw @ best.com