Am Mittwoch, 23. Oktober 2002 15:41 schrieb Alan Stern:
> Adding a semaphore is definitely the wrong solution.
>
> The problem of immediately cancelling all URBs when a disconnect occurs
> exists throughout the usb-storage driver, not just in usb_stor_clear_halt
> and usb_stor_reset_common. It needs to be solved at a higher level.
If you can come up with a workable scheme to do that, I'd like to see it.
> Here's a suggestion that would help all existing usb drivers. Add an
> additional parameter to usb_control_msg (and the other synchronous message
> subroutines as well) that takes a struct urb **. The subroutines can use
> it to store a pointer to the dynamically allocated URB, so that the driver
> would have the ability to cancel the URB whenever it wanted.
No, not whenever, only after the synchronous call has set the pointer.
Which you cannot know.
> (Alternatively, a more object-oriented -- and more correct -- approach
> would make the additional parameter be a pointer to some sort of handle.
> This handle could then be passed to a core subroutine that would use it to
> identify and cancel a synchronous message and delete the corresponding
> timer as well.)
>
> Adding this facility would simplify not only disconnect handling but also
> scsi-generated aborts in usb-storage. Of course, it would also require
> altering any driver that sends a synchronous message. Oliver, what do you
> think?
I think that it won't work. The correct sequence is:
...
down()
if (device_not_disconnected)
synchronous_call()
up()
...
and in disconnect():
down()
mark_as_disconnected()
up()
As you can see, the check for disconnection cannot be in the synchronous
helper.
The solution you suggest only works if you can ensure that the synchronous
call has given you a handle to unlink the urb before disconnect() runs.
To do so requires the synchronous helper to be called with a lock against
disconnect() already held.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
