OK, what about a compromise.

The fundamental problem that we all agree on is that SCSI devices are detected 
in the order that the mid-layer hosts.c file calls their detect routines.  
Further, for multiple cards of the same type, the detection order is up to the 
individual driver.  A different problem is that SCSI targets and LUNs are 
mapped sequentially to /dev/sd[a-z][a-d] so if you lose a device from the 
middle the ordering shifts.

I think that devfs does a very good job of addressing the latter problem, 
since you can now use it's naming scheme to find the exact target/lun you were 
looking for.

The former problem is really something that affects all adapter cards in the 
linux system (you have a similar problem for multiple ethernet cards, etc.)

One of the ways this could be solved would be to impose bus ordering on the 
detection sequence.  Since every computer bus (except the ancient ISA) has a 
way of getting its logical slot numbering (which is not necessarily related to 
physical slot numbering), you can easily impose this type of ordering on all 
card detection.  Doing this would necessitate some surgery in the way device 
detection is done, probably major enough to make it a 2.5 feature.

The up side would be that, as long as you maintain your cards in the same 
slot, the SCSI ordering would remain the same (you could even change the card 
and still have the same order).

The compromise over UUID detection is that if you change the slot, all bets 
are off.

If there is sufficient interest in this, I could look at putting together a 
patch to 2.4.x which would implement the scheme.

James Bottomley


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/