From: Luben Tuikov <luben@splentec.com>
To: Andries.Brouwer@cwi.nl
Cc: mdharm-kernel@one-eyed-alien.net, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org,
linux-usb-devel@lists.sourceforge.net
Subject: Re: inquiry in scsi_scan.c
Date: Sun, 05 Jan 2003 14:36:54 -0500 [thread overview]
Message-ID: <3E188956.9090907@splentec.com> (raw)
In-Reply-To: <UTC200301051307.h05D7da08203.aeb@smtp.cwi.nl>
Andries.Brouwer@cwi.nl wrote:
>
> The SCSI code has no means of knowing the actual length transferred,
> so has no choice but to believe the length byte in the reply.
> But the USB code does the transferring itself, and knows precisely
> how many bytes were transferred. If 36 bytes were transferred and
> the additional length byte is 0, indicating a length of 5, then the
> USB code can fix the response and change the additional length byte
> to 31, indicating a length of 36. That way the SCSI code knows that
> not 5 but 36 bytes are valid, and it gets actual vendor and model strings.
>
And what if the transport is *not* USB? Or they used
a similar firmware of their device server in another
product which used another transport?
I suggest that this device is blacklisted in that
SCSI Core would know that the ADDITIONAL LENGTH field
in the INQURY response is incorrectly set (to 0).
I.e. leave it to the interpreter.
A transport is *not* supposed to peek and poke in the
data it transfers!
--
Luben
next prev parent reply other threads:[~2003-01-05 19:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-05 13:07 inquiry in scsi_scan.c Andries.Brouwer
2003-01-05 19:36 ` Luben Tuikov [this message]
2003-01-05 20:54 ` Zwane Mwaikambo
-- strict thread matches above, loose matches on Subject: below --
2003-01-05 21:42 Andries.Brouwer
2003-01-06 20:52 ` Patrick Mansfield
2003-01-05 21:35 Andries.Brouwer
2003-01-05 22:05 ` Luben Tuikov
2003-01-04 3:24 Andries.Brouwer
2003-01-04 3:07 Andries.Brouwer
2003-01-05 0:41 ` Matthew Dharm
2003-01-04 0:21 Andries.Brouwer
2003-01-04 1:04 ` Matthew Dharm
2003-01-04 2:14 ` Douglas Gilbert
2003-01-04 2:44 ` Patrick Mansfield
2003-01-05 0:45 ` Matthew Dharm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E188956.9090907@splentec.com \
--to=luben@splentec.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=mdharm-kernel@one-eyed-alien.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox