From: Luben Tuikov <luben@splentec.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andries.Brouwer@cwi.nl, mdharm-kernel@one-eyed-alien.net,
linux-scsi@vger.kernel.org,
linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] Re: inquiry in scsi_scan.c
Date: Mon, 06 Jan 2003 11:43:57 -0500 [thread overview]
Message-ID: <3E19B24D.1080500@splentec.com> (raw)
In-Reply-To: Pine.LNX.4.33L2.0301060956210.740-100000@ida.rowland.org
Alan Stern 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.
>
>
> I'm not familiar with the details of the SCSI code you are referring to,
> but usb-storage does make available the actual transfer length. All the
> transport routine paths set the resid field of the Scsi_Cmnd structure
> properly. With this information, there should be no difficulty in
> determining how many bytes were transferred. (Maybe the setting doesn't
> percolate up to the particular code you mention -- and maybe other host
> adapter drivers don't set resid correctly so you cannot rely on its value.
> I don't know what other problems might crop up.)
In this most recent case reported, this looks very similar to
overflow residual, but not quite the same. I.e. *more* data is
actually immediately available (in the buffer) than *we requested* or can
find out by other means (i.e. checking the ADDITIONAL LENGTH field).
But if we requested 36 and the transport provided 36 then the
residual should be 0 (set by the transport). Had we requested 5 and the
transport provided 36 then the residual should be 31, but there's no way
of reporting this residual, since it is an *overflow* residual, and from
the comments therein, cmd->resid is *only underflow* residual.
Thus, *if* the cmd->resid field is set properly, then something like this,
in SCSI Core, might suffice:
</Disclaimer: this is NOT actual C code, but should be descriptive enough/>
int bytes_requested = <whatever>;
int bytes_got, additional_len;
...
</ok, we got response from INQUIRY/>
additional_len = buffer[4];
bytes_got = max(bytes_requested - cmd->resid, 0);
</now use bytes_got exclusively and ignore additional_len/>
...
</do assignments and whatever, and just before we're done print
a nice warning message if bytes_got != additional_len+5 />
--
Luben
next prev parent reply other threads:[~2003-01-06 16:43 UTC|newest]
Thread overview: 14+ 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
2003-01-05 20:54 ` Zwane Mwaikambo
2003-01-06 15:03 ` [linux-usb-devel] " Alan Stern
2003-01-06 16:43 ` Luben Tuikov [this message]
2003-01-06 18:54 ` Alan Stern
-- strict thread matches above, loose matches on Subject: below --
2003-01-06 19:18 Andries.Brouwer
2003-01-06 19:22 ` Matthew Dharm
2003-01-06 20:49 ` [linux-usb-devel] " Luben Tuikov
2003-01-06 21:03 ` James Bottomley
2003-01-06 21:05 ` Matthew Dharm
2003-01-06 21:16 ` [linux-usb-devel] " Luben Tuikov
2003-01-06 22:07 ` Doug Ledford
2003-01-06 22:10 ` Doug Ledford
2003-01-06 22:23 ` Doug Ledford
2003-01-07 0:46 ` Matthew Dharm
2003-01-07 3:42 ` Doug Ledford
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=3E19B24D.1080500@splentec.com \
--to=luben@splentec.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=mdharm-kernel@one-eyed-alien.net \
--cc=stern@rowland.harvard.edu \
/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