Re: [example PATCH - not for applying] exclude certain commands

[Matthew Dharm <mdharm-scsi@one-eyed-alien.net>]

[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]

On Sat, Apr 26, 2003 at 05:43:43PM -0500, James Bottomley wrote:
> On Sat, 2003-04-26 at 17:13, Matthew Dharm wrote:
> > > Of course it is bad when variables have a function that differs
> > > from what is suggested by their name. So, sr_bufflen must be
> > > the length of the buffer and nothing else. If the length of
> > > the transfer is needed, there must be a field sr_xferlen or so.
> > 
> > Sounds good.  It also sounds very similar to what I proposed some time ago.
> > Here's a question from that discussion: How you you set sr_xferlen?  I'm
> > guessing that you want to add a parameters to scsi_wait_req()?  Or
> > will you simply remove the bufflen parameter and force callers to set both
> > fields in the struct scsi_request?
> > 
> > Either way, you'll be touching a great deal of code.  Which isn't
> > necessarily a bad thing, but it might raise a few eyebrows....
> 
> What's actually wrong with simply parsing the commands?  For all SCSI
> Spec commands there's a well known algorithm to get the transfer size
> from the command group.  For vendor specific commands, well the
> mid-layer doesn't issue them so you'd just have to rely on the user
> doing it to pass the correct buffer length (which is no different really
> from what happens today).

To parse correctly, I would need to remember what type of device it is by
snooping the INQUIRY data.  I would also have to keep around data such as
block size (for TYPE_DISK).  I haven't even looked at what extra data I
would need to keep around for all the other types.

Why should usb-storage do that when someone else (the command source)
already knows this data?  Whatever is sending the command already knows how
much data to expect -- my reparsing the command to try to figure it out is
guaranteed to be less precise than just using the correct answer from the
source of the command.

Also, user-issued commands can specify buffer size and transfer length
separately, but only one value gets given to the usb-storage driver.  The
other is dropped on the floor somewhere in the mid-layer.

In the end, I guess the short-answer to 'what is wrong with parsing' is
that we tried it for over a year, and it kept biting us on the ass with
weird corner-cases and strange devices.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

We can customize our colonels.
					-- Tux
User Friendly, 12/1/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]