On Fri, 2 Oct 1998 20:18:45 -0400 (EDT)  Greg A. Woods wrote:

> Oh, of course it does, but that's most emphatically *not* the problem
> the /dev/disk/cNtNdN problem is trying to solve.  What it does do is
> make a guaranteed 100% accurate way of determining what /dev node refers
> to what physical device.  I.e. you can manually peer in at the back of
> the controller card, all the cabling, and the jumpers/switches on the
> drives, etc., and be 100% certain what /dev node you must use to access
> any given device.

Which "guarantee" doesn't apply on HP-UX or Solaris.

On HP-UX you need both the hardware path and the "instance number"
to map a device to /dev/dsk/cNtNdN.  Fortunately ioscan is smart
enough to show you the instance number, and there is lssf to further
translate but just physical examination won't do it.

On Solaris (which is SysV, for some values of SysV :-) the picture
is just as confused as you have to follow the /dev symlinks to find
the corresponding /devices entries, which I *think* refer to actual
unchanging hardware paths.  Someone will correct me if I'm wrong.  :-)

> Any changes to the hardware configuration *should* cause the mapping of
> device nodes to the hardware that moved to change

The problem is that people don't always add controllers in the same
order that an OS installation would probe them in.  For better or
worse both HP-UX and Solaris "preserve" the previous mappings when
you install new hardware.

Usually this is a good thing, but it means you have to be on your
toes when you re-install a machine that has a different hardware
configuration to what it had when it was first installed.

(On HP-UX at least the mappings may be manually specified, if you
play enough with rmsf and insf.)

All of these mapping schemes plus BSD hardwiring and even Windows
registry entries make it hard to move a boot disk from one machine
to another.  Mostly, this is "unsupported".

> BTW, in a scheme where mount(8) can mount by label name then I'd expect
> the kernel to provide a function that will either directly eliminate the
> use of /dev (eg.: openlabel(label, mode) returns a file descriptor), or
> will at worst return the appropriate name in /dev for mount to use.
> After all the device drivers read the label and thus d_packname already.

Makes sense.

Might have to think somewhat again about who can mount what if
/dev/dsk "goes away".

This would also provide a better abstraction for what modern smart
(RAID etc) disk enclosures do.  Having utilities to "create" SCSI
LUNs always seems strange to me!

Giles