On Tue, Nov 06, 2007 at 08:40:41AM +0000, Andy Greensted wrote:
> Alan Stern wrote:
> > There are two possible approaches. The easy way is just to use a very,
> > very long timeout. Alternatively, when a timeout does occur don't
> > return to the user; instead loop back and submit another usb_bulk_msg.
Alan, Andy, forgive me missing this part of Alan's message.
> As suggested, I've modified my driver to continually retry a
> usb_bulk_msg if a timeout occurs (ETIMEDOUT is returned). My read
> function now only returns if data has been read, or another error type
> occurs.
>
> The only problem now is that a program reading from my device will not
> respond to a ^C (or kill). I guess it's stuck in the read loop waiting
> for data!
For that you need my suggestion to check for signals. Just grep a bit
in the kernel sources and you'll find an example.
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
