According to Greg A. Woods:
>
>> Not sure what you mean by a "real" machine here ;-).  I would defy you
>> to pick c2 on a Sun after a few adds & removes of hardware with doing
>> a "boot -r" in between.
>
>Again, I'm most definitely *not* referring to Solaris.  I'm talking
>only about the hardware itself.
>

Aaaah that's a bit weasly :-)  The hardware can wriggle and dance all
it likes but, ulitimately, it's what the OS presents to you that needs
to make sense.  It does not matter if you can reliably say that the
scsi bus in sbus slot 2 will always be at a particular place hardware
wise - if the OS says that it is c9 for what ever reason then what
does that buy you?

>It's not specifically the naming convention (though that is useful for
>us humans who don't have accurate arithmetic calculators wired into our
>brains), but rather the implications of the scheme.  I.e. specifically
>the implication that disks and controllers are always wired to specific
>and predicable /dev names.
>

You do assume that you can reliably work out what controller is what
in some deterministic manner.  Are you going to suggest that we
associate a particular device number (we are using the scsi bus here a
lot but this should apply to any device that supports child devices)
with a particular slot? i.e. if the card is in slot X then this must
be controller foobarN

>
>The direct benefit of such a naming scheme is that it maps with a
>one-to-one correspondence on the way most people I know describe their
>hardware configurations.  I never think in terms of "disk 99" I think of
>the disk set to target 3 on my fourth SCSI bus, or whatever.

The presumption is that you know what your fourth scsi bus is.  This
is something that can be very difficult to determine.

>  I have to
>look at the manual pages or source code and run 'bc' to figure out that
>it's really going to be "disk 99" (either that or actually attach it and
>reboot and then run "dmesg | more" to figure this out).
>

Or format or prtconf.

>The benefit of having disks always wired down is that they never move if
>one breaks or another is added in between (i.e. SCSI target wise).
>

Which we can do with the current scheme - you can wire down what you
have and leave an auto-probe to catch newly added devices.  This gives
you low overhead and flexibility.

>Auto-configuration is somewhere between good and great in certain
>cirumstances, but when it comes to critical system devices, such as
>disks, ethernet cards, ttys, etc., it can go too far too.
>

But IMHO it is an all or nothing.  Either you go the whole hog and
autoconfigure the system or you use a kernel config.  Any hybrid would
be a monster.

-- 
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================
  And the monks would cry unto them, "Keep the bloody noise down!"
  - Mort, Terry Pratchett.