[ On Fri, October 2, 1998 at 17:38:12 (-0700), Curt Sampson wrote: ]
> Subject: Re: Another changer, another changer problem 
>
> On Fri, 2 Oct 1998, 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.
> 
> But we can already do that now just by looking at the boot output
> to see which thing was assigned to which. If you want to hardwire
> that, you can do so easily enough in your kernel config file.

Looking at the boot output is *not* the way to do these things.

To change this takes major hacking in the system, including the concept
of defining "classes" of drivers (eg. "disk" drivers) so that they can
all share a major number, etc. or some other similar magic so that one
can always rely on the filesystem having a /dev/disk/c0d0t0 that
corresponds to the first disk on the first controller, regardless of
what kind of controller or disk it might be, or even what system bus it
might be on.

The alternative is to use a defvs kind of concept with a naming scheme
similar to one of the ones that's been previously proposed.  I.e. to
completely avoid the old major/minor number consistency problem and to
go fully dynamic, assigning device names based on bus attachments and
ensure that everything corresponds to the physical attributes such as
connector type, bus slot, address select, etc. as appropriate.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>