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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
