public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
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



  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