On Fri, 4 May 2001, Martin Diehl wrote:
> 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.
True.
> 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.
You would give data requested by one task to another.
Probably this is legal. Nice it isn't.
In addition you now have to deal with incomplete buffers.
This is getting complicated.
> > 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
Yes, copy to user or error handling. Returning an error caused by another
read by another task is nasty.
> 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.
Yes.
> > 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,
Really ? No read from signal handlers ?
> 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.
I still think it's easier to kill the urb.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
