Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58

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

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

On Fri, Jan 17, 2003 at 11:55:36AM +0100, Oliver Neukum wrote:
> That is simply wrong. Reporting somebody having pulled a plug must
> not fail. What are you supposed to do with an error here?
> 
> There must be a way for a LLD to report that reliably.
> If the answer is, take that lock, call that function, error all pending
> requests, release that lock and call that function, it's OK.
> 
> But it must work in all cases.

I absolutely agree.  The device is gone.  I can't do anything about it.
If the SCSI layer decides it can't let go, what am I supposed to do about
it?

In a separate discussion with Mike, he mentioned that you can't
scsi_remove_device() unless there are no pending commands.

How the hell is an LLD supposed to assure that!?!?

The minute I error a command and call scsi_done(), I can get a new one.
Unless I lock out requests with scsi_block_requests(), but that comes with
major warnings about needing to get unblocked.

The way this should work is that the LLD calls scsi_remove_device(), and
that cuts off the flow of commands.  The LLD can promise to error-out any
pending commands in the device command queue.

That is, unless scsi_block_requests() and scsi_unblock_requests() are more
useful than the documentation suggests... block(), error all commands, 
unregister()... that would make some sense.  We could call
scsi_block_request() as soon as we know the unit is gone, and unregister()
as soon as the queue is empty.

Matt

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

A:  The most ironic oxymoron wins ...
DP: "Microsoft Works"
A:  Uh, okay, you win.
					-- A.J. & Dust Puppy
User Friendly, 1/18/1998

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