[ On Mon, October 5, 1998 at 10:44:37 (-0700), Bill Studenmund wrote: ]
> Subject: Re: Another changer, another changer problem
>
> On Sun, 4 Oct 1998, Greg A. Woods wrote:
> 
> > I think all of Bill's confusion comes from a simple off-by-one
> > assumption he's making.  I don't quite know why, since I *never*
> > mentioned "major" numbers when talking about the idea of having a fixed
> > "minor" number to reference the raw disk....
> 
> But Greg, that's in-band! :-)

OK  ;-)

> But that's basically what we do now, except you've decided to use 0
> instead of 2 or 3 (c/d). Granted that if we have 64 partitions, we might
> not notice, but it still is a minor number, in-band with all the others.

No no, that's not all!  I've also divorced the raw disk from the
partition table.  That's the key to my whole proposal.  It always should
ahve been that way.  The "raw disk" is the *raw* disk!  It is not a
partition!  I don't care if the offset is '0', or MAXPARTITIONS (i.e. 8,
16, 22 where partition 'a' is 0) or even if it's something in the
middle.  I just don't want it to refer to a member of the d_partitions
array.

> Ack! But VERY few devices EVER have more than one LUN. To reserve all this
> space (7/8ths of it) for a rarity seems a waste. And it is a step
> backwards from our current scsi layer, where we've eliminated the
> necessity of reserving all this device space.

LUNs are in the spec.  Violate the spec. at *your* own peril, not mine!  :-)

Why do you think devices which don't obey LUN probes a la the spec are
called "quirky"?  If NetBSD doesn't obey LUNs then it's quirky too!

How would you support those SCSI devices that do use LUNs if you don't
map them *all* into the minor-number offest?  Doing this *might* be
possible with a dynamic devfs, but I see no other way in the hard-wired
world of major and minor numbers but to allocate space for them
regardless.  Any other ideas are here-by solicited.

> But we still have the problem we started with: you can tie devices to
> scsibusX, but you still can't tie them to a particular controller. If one
> of your controllers dies, all the higher numbered busses re-number.

Even worse -- it doesn't have to be a hardware failure.  A simple change
to a device driver can totally screw up the probe order.

That's why I detest numbering devices by probe order and why I like
little jumpers, switches, or *physical* slot position.  You can never
rely on simple order if something can happen to cause the probe to leave
one of the devices out of the count.  If I have three host adapters, and
the one of the first two dies or is otherwise missed by the probe then I
still *require* the third one to appear as scsibus3.  Period.  If this
is not possible on some given platform then I want to see a big fat
warning in one or more places in NetBSD to remind me *never* to try and
put more than one controller of a given type in that system.

> The only way to nail the scsibusses down is in a kernel config. In the
> same way which would nail the devices down now. Since that idea is not
> acceptable, we will have added a fair amount of bloat (all these major
> and minor numbers used for little gain) and we still don't have things
> wired down.

That's not going to work if you assign controllers to buses based on the
probe order.  There *must* be some way to physically identify the card
in order to prevent sliding your disks around accidentally.

> If you have a server where you care what's where and you want things to
> work even if controllers go down, you MUST wire EVERYTHING down. No more
> ncr* at blah.

I agree whole-heartedly.

-- 
							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>