The following patch for linux-2.5.22 provides support in driverfs for scsi devices including st, sr, sg, sd (and partitions). For the most part the implementation follows the architecture set by Patrick Mochel for the PCI device tree. The primary difference is an attempt to use info obtained from the Scsi Inquiry pages to create the content of the driverfs "name" file for each Scsi device. This code can be found in the scsi_scan.c portion of the patch. The goal of this extra code is to provide a name that can uniquely identify a device independant of it's topology or discovery order.
The patch is also available at http://www-124.ibm.com/devreg/linux-2.5.22-driverfs.patch.gz
I would welcome any feedback or comments. Please copy me directly on your replies...
I get a BUG in device.h:213 trying to insert the st.o module, but other than
that, it seems to be running OK.
You forgot to export the symbol scsi_bus_type which is needed for sd et al. to
compile as modules.
This code:
+/* Driverfs file content handlers */
+char * scsi_type_names[] = {
+ "DISK",
+ "TAPE",
+ NULL,
+ "PROCESSOR",
+ "WORM",
+ "ROM",
+ "SCANNER",
+ "MOD",
+ "MEDIUM_CHANGER",
+ "COMM",
+ NULL,
+ NULL,
+ NULL,
+ "ENCLOSURE"};
Duplicates the scsi_device_types array (in scsi.c), but with slightly
different names. Could you use the same array? otherwise we're going to get
different device types from driverfs and /proc/scsi/scsi.
And, of course, for a legacy array, all the LUNs have the same name:
3:0:3:0/ 3:0:3:1/ 3:0:3:2/ 3:0:3:3/ name power
jroot@malley> cat 3\:0\:3\:*/name
S1T41711424NCR
S1T41711424NCR
S1T41711424NCR
S1T41711424NCR
James
Oops trace for st insert:kernel BUG at /mnt2/jejb/BK/BUILD-2.5/include/linux/de
vice.h:213!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0178624>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000 ebx: f7d7e000 ecx: 00000000 edx: f7d7e004
esi: f88c81a0 edi: fffffff4 ebp: f7d7e3c4 esp: f7c5be68
ds: 0018 es: 0018 ss: 0018
Stack: f7d7e000 00000000 f7d7e3c4 f7c5bee4 f88c67a9 f7d7e3c4 f88c81a0 f7d7e3c4
f7d7e0a4 00000000 f7d7e130 f7d7e0e0 00000140 00000160 00000900 f7d7e0b4
f7d7e3f0 00000450 00000470 00000980 f7c5bee4 f7d7e004 f7d7e008 f7751d2c
Call Trace: [<f88c67a9>] [<f88c81a0>] [<f88c8080>] [<f88096aa>] [<f88c6c78>]
[<f88c8080>] [<c011afc7>] [<f88c82ec>] [<f88c1060>] [<c0108977>]
Code: 0f 0b d5 00 c0 76 20 c0 f0 ff 85 90 00 00 00 68 f0 01 00 00
>>EIP; c0178624 <device_create_file+24/80> <=====
Trace; f88c67a9 <[st]st_attach+489/760>
Trace; f88c81a0 <[st]st_device_type_file+0/20>
Trace; f88c8080 <[st]st_template+0/90>
Trace; f88096aa <[scsi_mod]scsi_register_device+aa/140>
Trace; f88c6c78 <[st]init_st+58/a0>
Trace; f88c8080 <[st]st_template+0/90>
Trace; c011afc7 <inter_module_put+797/870>
Trace; f88c82ec <[st].bss.end+1/6>
Trace; f88c1060 <[st]st_incompatible+0/f0>
Trace; c0108977 <__read_lock_failed+1137/3740>
Code; c0178624 <device_create_file+24/80>
00000000 <_EIP>:
Code; c0178624 <device_create_file+24/80> <=====
0: 0f 0b ud2a <=====
Code; c0178626 <device_create_file+26/80>
2: d5 00 aad $0x0
Code; c0178628 <device_create_file+28/80>
4: c0 (bad)
Code; c0178629 <device_create_file+29/80>
5: 76 20 jbe 27 <_EIP+0x27> c017864b
<device_create_file+4b/80>
Code; c017862b <device_create_file+2b/80>
7: c0 (bad)
Code; c017862c <device_create_file+2c/80>
8: f0 ff 85 90 00 00 00 lock incl 0x90(%ebp)
Code; c0178633 <device_create_file+33/80>
f: 68 f0 01 00 00 push $0x1f0
On Mon, Jun 17, 2002 at 06:16:53PM -0500, James Bottomley wrote:
> I get a BUG in device.h:213 trying to insert the st.o module, but other than
> that, it seems to be running OK.
Thanks James. Attached is an updated patch that fixes the st.o module and incorporates your other suggestions. The updated patch is also available at
http://www-124.ibm.com/devreg/linux-2.5.22-driverfs.patch.gz