The utility that I described generates entries like:
total 0
crw------- 1 root root 9, 128 Aug 4 13:16 rsth4c0i5l0
brw------- 1 root root 8, 0 Aug 4 13:16 sdh4-334c0i0l0
brw------- 1 root root 8, 1 Aug 4 13:16 sdh4-334c0i0l0p1
brw------- 1 root root 8, 2 Aug 4 13:16 sdh4-334c0i0l0p2
brw------- 1 root root 8, 3 Aug 4 13:16 sdh4-334c0i0l0p3
crw------- 1 root root 21, 0 Aug 4 13:16 sgh4-334c0i0l0
crw------- 1 root root 21, 1 Aug 4 13:16 sgh4-334c0i2l0
crw------- 1 root root 21, 2 Aug 4 13:16 sgh4-334c0i5l0
br-------- 1 root root 11, 0 Aug 4 13:16 srh4-334c0i2l0
crw------- 1 root root 9, 0 Aug 4 13:16 sth4-334c0i5l0
Given entries like this, then it is possible to grab devices
by controller:deviceid. The numbers for disks are
sdh4 - disk, attached to host type 4 (i.e. aha1542).
-334 - identifies which 1542, in this case the I/O port it is using.
c0 - channel 0 (1542 only has one chan, others have more than 1)
i0 - scsi id 0
l0 - scsi lun 0
p1 - partition 1
If you are asking about a fixed mapping of minor numbers to
devices, then this is not possible with a 16 bit dev_t (where you have
8 bits for the minor). With a 32 bit dev_t, it is still easily
arguable that you do not have enough dynamic range to cover all of the
possibilities without making assumptions about the ranges of some of
the numbers, esp if you split it 16/16. I have even seen someone
argue that you need about 48 bits for the minor number to allow for
all of the possible permutations involving disk drives.
If and when a larger dev_t is implemented, we might recondsider
and attempt to implement a fixed-mapping for scsi, but as of the moment
there are no plans to change the mapping.
> be in the machine at the time. Also, has proc/scsi
> been working in the newer kernels? I was going to
Yes, this is working again.
-Eric