On Wed, 23 Oct 2002, David Brownell wrote:
> What I'd thought about was instead to just provide the URB to unlink
> if the timeout failed, device was disconnected, or whatever. Why ask
> for some new api notion? In fact I think I have code sitting somewhere
> around here that does exactly that, maybe I should dig it up...
>
> That means synchronous callers could
>
> dev->some_urb = ... alloc+save, locked against disconnect ...
> ... setup timeout to unlink the urb ...
> sync_control_message (urb, bRequest, bRequestType, ...,
> INTERRUPTIBLE or maybe not)
> ... cancel that timeout
> switch (urb->status) {
> ...
> }
> free dev->som_urb
>
> and the disconnect code could just unlink all active/submitted urbs.
Is this intended to be pseudocode that is executed in the driver? What's
the advantage of this over a roll-your-own synchronous message using
usb_submit_urb()? The only reason for having the synchronous message
routines in the core was to provide the convenience of not having to
allocate a URB, not having to set up a timeout, and not having to
deallocate everything at the end. This just puts all that overhead back
into the driver.
But as Matt Dharm pointed out, having the core/HCD automatically cancel
any URBs for a disconnected device (and refuse to accept new submissions
as well) would provide the most straightforward solution -- at least, from
a device driver author's point of view.
Alan Stern
-------------------------------------------------------
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
