On Thursday, 3. May 2001 18:37, you wrote:
> 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?.
Whatever you report to user space is not relevant for the problem.
After an URB has completed, you need to process the buffer or you'll lose
data.
> 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
It's not simply ready, you need to process the buffers, which you cannot do
in interrupt.
> block again or timeout. fop->release (i.e. close(2)) is a different story
> of course.
Blocking is not so easy. Which task do you wake up if the signal handler does
IO ?
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
