On Fri, 4 May 2001, Oliver Neukum wrote:
> 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.
I still don't see the problem. The driver detects there is a signal
pending and returns EINTR. At this point the URB is still pending -
i.e. we don't neither know whether it's still in progress or not and
haven't done any processing. Hence the driver must not make any
assumptions about this URB's status. Nothing is lost so far.
Whenever the next syscall happens to read/write more data,
the driver remembers the pending URB, checks its status and makes the
usual decision. If ready, use the data, if not, sleep or timeout.
> > 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.
What do you mean by "process the buffers" - copy_to_user()? I don't see
any need to do this in completion handler. Ah wait, you want to resubmit
the URB immediately from whithin its completion handler? Then you'll need
to copy its contents into a temporary buffer anyway, I believe.
I personally prefer an ordered pool of URB's. Let's assume, read(2) f.e. is
just processing the "current one". If this is finished, resubmit it and
switch to make the next one in the pool the current one. On next read(2),
sleep if current is still EINPROGRESS.
> > 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 ?
Hm. read(2) is known to potentially block. Hence it is illegal to call it
from the signal handler. If you make it non-blocking, we'll never block,
the test is there (at least for printer.c). If the remembered urb is found
completed now, we can return the data without blocking, if not: EAGAIN.
But haven't looked at nonblocking close(2). You obviously have to wait for
the pending URB's beeing unlinked. Probably schedule some tasklet to clean
it all up.
Martin
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
