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

Reply via email to