> > 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.
Very good.
> - 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
Yes, extremely good, we _need_ this.
> 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.
Meaning? If memory stays tied up, we have a beautiful DOS attack,
if disconnection can be faked by software.
Regards
Oliver
-------------------------------------------------------
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
