[lkml]   [2001]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH: scsi_scan.c: emulate windows behavior
Rob --

This patch doesn't prevent another application from getting more INQUIRY
bytes. What it does change is how much data the SCSI scanning loop looks
for. That data is requested, and then thrown away. It's not kept around
for anything.

If it were kept, I'd agree with you. But it's not. Some useful data is
copied out of the INQUIRY result, and then the buffer is overwritten by the
next probing request.

I can't see any code in the SCSI scanning section that looks beyond the
first 36 bytes.

Also, some devices just die if the INQUIRY is anything but 36-bytes. Since
all the data beyond the first 36 is considered vendor-specific, I would
expect a driver to _check_ the first 36 bytes to see if this is an
apropriate device, and then (and only then) request more data.


On Tue, Nov 13, 2001 at 08:49:09PM +0100, Rob Turk wrote:
> "Matthew Dharm" <> wrote in message
> >Attached is a one-liner patch to scsi_scan.c, which changes the length of
> >the INQUIRY data request from 255 bytes to 36 bytes. This subtle change
> >makes Linux act more like Win/MacOS and other popular OSes, and reduces
> >incompatibility with a broad range of out-of-spec devices that will simply
> >die if asked for more than the required minimum of 36 bytes.
> >Matt
> Matt,
> Many devices have useful information in the bytes beyond 36. Media changers from
> various vendors are starting to use byte 55 bit 0 to flag if a barcode scanner
> is present. Other devices have revision levels and/or serial numbers there.
> Getting more than 36 bytes should not be a problem for any device. The root
> problem seems to be that 255 is an odd number. On Wide-SCSI, a lot of devices
> have difficulty handling odd byte counts as they have to use additional
> messaging to flag the residue in the last 16-bit transfer. Also, the IDE-SCSI
> layer has trouble, as the IDE spec doesn't allow odd byte transfers at all. I've
> experienced issues with IDE devices that had to have their firmware patched just
> to deal with the Linux odd-byte request. Maybe a better change would be to use
> 64 or 128 byte requests. Your thoughts?
> Rob

Matthew Dharm Home:
Maintainer, Linux USB Mass Storage Driver

It's not that hard. No matter what the problem is, tell the customer
to reinstall Windows.
-- Nurse
User Friendly, 3/22/1998
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 13:18    [W:0.076 / U:4.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site