Oliver and Alan I am trying to catch up on this thread so I did not
reply directly to your concerns, but I think they are covered below.
Matthew Dharm [[EMAIL PROTECTED]] wrote:
> 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!?!?
>
I believe that the scsi_remove_host function the way it is currently is
not the correct function. The SCSI needs to separate the device gone
from freeing. There maybe some unbounded cleanup as the request_queue
that is exported to the block layer is part of the scsi_device which is
a child of the virtual usb SCSI adapter. The only way to reduce the
unbounded time is possibly we reorganizing some sysfs tree object
layouts.
> 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.
>
Well in the case of the device really being gone does the LLD need to be
worried about being unblocked. I get the feeling from this thread that
this is probably the wrong interface.
> 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.
We should really ensure that we have good separation between stopping device
IO, device gone, and release resources.
- SCSI seems to have the flags to stop the IO, but instead of
scsi_block_requests we may want to export the setting of
device online. This can be done from sysfs now, but
not from the driver ( the driver does have a handle to the
device, but it would be better to have an interface in case we
need to do something addition operations).
- Possibly add a scsi_remove_device that would always succeed and
a version of scsi_remove_host that calls scsi_remove_device for
all devices. Though with the recent change to SCSI remove host to
allow non sysfs device registration I do not believe we could
ensure devices would be cleaned up.
- SCSI would need to support ref counting so that resources are
not removed to soon.
-andmike
--
Michael Anderson
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
