On Mon, 5 Oct 1998, Greg A. Woods wrote:

> [ On Mon, October 5, 1998 at 10:44:37 (-0700), Bill Studenmund wrote: ]
> > Subject: Re: Another changer, another changer problem
> > 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.

I agree that it'd have been nice if the raw disk weren't 'c' (and
especially not 'd'). You do realize that the partition table isn't looked
at for RAW_PART, don't you? Partition RAW_PART will ALWAYS give you the
full disk.

> > 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!  :-)

I'm not saying we should ignore LUN's. Just that there are cleaner ways to
support them. Right now, the scsi layer will attach a disk (or tape or cd
or ...) where ever they are found. That way we only use unit space for
units we really have (or we want to reserve space for).

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

Do it the way we can now! :-) Hard-wire it in the kernel. Map only the
ones which exist. If a drive has one LUN, hook up one LUN. If a drive has
8 LUN's, hook up 8. :-) 

Right now our scsi layer does two things. It only uses unit numbers for
found devices, not potential devices (i.e. you don't encode the target/LUN
in the unit field of the minor number) AND we dynamically scan for things.

You, I, and everyone else (I think) agree that you want to wire down
things in a production environment (at least you agreed in the end of the
message I'm quoting :-)    Given that, you can say sdX at scsibusA target
b lun c for each unit you know you have (and the units you think you might
have). We've effectivly turned off the dynamic scanning. Well, the sd*
will catch all the devices which aren't wired down.

Given that you've now wired things down (and also wired the scsibus's to
respective controllers, and the respective controllers to I/O mappings -
either jumper settings or say to pci device number), you give things unit
numbers, and make respective device nodes.

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

As far as I know, it's possible on EVERY NetBSD platform, if you take the
time to wire things down in your kernel. Every device driver should
support both wildcard and wired-down locators, and should indicate that
the wired-down one is preferable. If a device driver doesn't, send a pr.
:-)

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

No one's mentioned it, but you can.

Here's a sample pciscsi line from the i386 GENERIC file:

ahc*    at pci? dev ? function ?        # Adaptec [23]94x, aic78x0 SCSI

make that

ahc1    at pci0 dev 12 function <whatever>
ahc2    at pci0 dev 13 function <whatever>

and you've just wired down two scsi controllers. 

On an eisa bus:

bha0    at eisa0 slot 4

wired down a bha.

Then

scsibus0 at ahc1
scsibus1 at ahc2
scsibus2 at bha0

sd0 at scsibus0 target 0 lun 0
sd1 at scsibus0 target 1 lun 0
sd2 at scsibus0 target 1 lun 1

and so on.

You can do this now. Today. With no changes to the kernel. Given that, I
think everyone will be loath to reserve space in major and minor numbers
to permit wiring things down. I mean to do this, you have to generate a
custom kernel (to tie scsibus's to specific controllers at specific
olcations), so why not wire sd's down too. 

Take care,

Bill