On Thu, 3 May 2001, Oliver Neukum wrote:
> Thinking more about it, I am not sure whether simply returning to user space
> with pending signals is valid. Pending signals do _not_ imply that the urb
> was not processed. IMHO you have to unlink the urb and check the result.
> If you were early enough you return, if not you need to process the data
> transfered.
Hm. You do probably not mean whenever the userland app has prepared a
timer for some purpose we need to unlink the URB on SIGALRM? Same for
SIGIO when doing asynch I/O for example. The userland app might even
prefer the syscall to restart after signal delivery (SA_RESTART).
Probably better to use ERESTARTSYS at some/most places?.
But you are right, the driver must not make any assumption about the state
of an urb if it escaped the blocking due to pending signal. IMHO it's the
drivers job to manage the state of all its urb's appropiately - pending
for completion or not. I don't see what's wrong if the driver looks at
urb->status at the next read(2) or whenever needed to find out whether it
is still EINPROGRESS or not. If not, it was apparently completed at some
time in the past (don't care when - it's ready now). If not ready, we
block again or timeout. fop->release (i.e. close(2)) is a different story
of course.
Martin
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
