On Oct 8, 12:15am, Greg A. Woods wrote:
} [ On Wed, October 7, 1998 at 15:44:59 (-0700), Bill Studenmund wrote: ]
} >
} > I think the main reason that you're getting so much resistance to this
} > argument is that you've only wired the disks to a controller. If the
} > controllers re-arange themselves, then you're just as hosed as you are if
} > you add a disk and you're using sd*. Wiring disks to controllers is not
} > really wiring them down.
} 
} I've been thinking about the controllers all along.  Remember when I
} suggested that all disk and network controller drivers be put under some
} generic layers similar to the way scsi controllers are all attached to
} a scsibusN now?
} 
} After all that's what the "cN" in /dev/dsk/cNtNdNsN is all about.
} 
} If I can identify the controller by bus slot number or some combination
} of jumpers and switches physically configuring it, then I should be able
} to keep it in the same place regardless of what's inserted near, before,
} under, or after it, etc..

     So this means that an empty slot, or a slot with something other
then a SCSI controller would need to be "assigned" a "cN".  Although,
it is probably possible, I don't know of any machine which does this.

} > I doubt that making a scsibus take up a whole major number will ever
} > happen. But some system which would be able to preserve device
} > configuration between boots would be interesting. And with it, the disks
} > could be wired down just as easily as the busses can. So sd2 could always
} > be at controller 3 target 5, even if controller 2 gains 20 disks.
} 
} That path leads down to the rocky road Solaris and HP-UX et al are
} already on now.....

     I thought you like the idea of disks not moving around.  Now you
say that "sdN" or "cN" should move around.  Make up your mind, which
is it?

} I now agree the only other obvious way to do this in a truely portable
} and scalable fashion is to build a virtual configuration space using
} sparse tables (eg. linked lists or btrees instead of bdevsw, etc.) so

     So much for efficiency.  Converting a simple array into a sparse
data structure is a wonderful way of greatly slowing down the system.
No thank-you!

} that every possible arrangement of hardware can be expressed in a single
} namespace and to invent and to use a virtual filesystem ala devfs that
} presents all of the hardware successufully probed in the system (and of
} course can dynamically make new devices appear following run-time probes
} so that I can remember to turn on my tape drive and not have to
} completely reboot).  Doing this might be good in the long run because it

     This doesn't require a devfs.  Just pre-assign the device, i.e.
"sdN at ...".  And, our current system does have the capability of
reprobing a scsibus.

}-- End of excerpt from Greg A. Woods