Alan Cox wrote: > > > > SCSI layer proper. The only problem I can see is a broken device > > > that violates the specs by truncating the additonal length > > > parameter to the buffer length provided. Other than that, > > > > I have the documentation from a scanner vendor which indicates exactly > > this broken behaviour. > > So we need a controller->default_inq_length ?
Sorry, I don't understand you question. What I meant was this: If understand Martin's proposal right, the SCSI layer should first issue a standard 36 byte INQUIRY, even if an application or high level SCSI driver wants to get more data; and if byte 4 of the returned data indicates that the device can provide more data, a second INQUIRY is issued. If the proposal would go into Linux's SCSI system in a way that it affects the handling of INQUIRY commands sent via the SG driver, this might break applications that want to read more than the standard 36 bytes from a certain scanner model. (Sorry, can't tell the vendor; it's not Sharp as might be suggested by the fact that I'm the co-author of the Sharp backend for Sane. I've only got the SCSI reference manual for the machine in question under a kind of an "informal NDA"; I don't have such a scanner available -- can only make comments based on reading the manual...) The manual states that if a "regular 36 byte" INQUIRY command is sent to the device, byte 4 of the returned data block is 31, thus indicating that there is not more than the regular INQUIRY data available, while the scanner can acutally provide more data, containing details about maximum scan size, scan resolution and so on. So, if the SCSI layer would clip the data block size to 36 bytes and send this "shorted inquiry" to this scanner, the returned value for "additional length" at offset 4 would prevent to issue a second INQURIY command to read the larger data block, which will break applications relying on the information from bytes at offset > 35. Generally, I think that the SG driver, the mid-level and the low level drivers should avoid messing with the details of a SCSI command -- they should simply pass a command to the device and return the result; any implicit assumptions about a SCSI command may lead to unneccasry hassles. An old example are the vendor specific commands for Canon scanners. The CDB size for these commands is not what some very old versions of the SG driver expected, hence the author of the Canon backend, Manuel Panea, recommended some patches to the driver. Abel _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel