On Fri, May 19, 2006 at 03:43:26PM -0400, James Smart wrote: > Matthew Wilcox wrote: > >scsi: 2:0:1:0 Device: HP 18.2G ATLAS10K3_18_SCA HP05 ANSI 02 > >scsi: 4:0:2:0 Device: HP DVD-ROM 305 1.01 ANSI 02 > > > >If we really wanted to be smart, we could even do: > > > >scsi: 2:0:1:0 Direct-Access HP 18.2G ATLAS10K3_18_SCA HP05 ANSI 02 > >scsi: 4:0:2:0 CD-ROM HP DVD-ROM 305 1.01 ANSI 02 > > I wouldn't bother with the device type, unless you are reporting it as the > byte0 contents (eg. PQ bits and dev type). I would like to see the PQ bits. > I also expect the class driver to typically bind to the device right after > this, so I'll get the sd or st lines which will further reflect device type. Ah, well, that's no longer true with the async scanning patches. They work by scanning all the luns first, then going back and adding the luns to sysfs. I did this to preserve drive naming. There were some other options I considered, but this was the simplest way of doing things. Looking at the device type stuff, I feel the urge to change the interface to it -- no longer export the array directly, but change it to a function which returns a string. That way we can pass in inquiry byte 0 and have it return an appropriate string based on PQ and PQT. > >I'm still in two minds about even reporting the ANSI version. Is there > >ever a time when having that information would be useful to debug a > >problem *and* we don't have access to that (eg through sysfs)? > > It makes a difference if debugging a scan issue. I would think it's useful > to see what Lun 0 has as it drives other scanning. Certainly -- but don't we get sysfs access to debug this kind of problem? Or do people sometimes have this problem and can't find their root device as a consequence? - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
