All of lore.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: 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
2003-01-05 20:54 ` Zwane Mwaikambo
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.