On Fri, 4 May 2001 [EMAIL PROTECTED] wrote:
> > 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.
Ok, see the point for multiple readers. Do you know what happens if you
have two readers on /dev/ttyS0 asking for 10 bytes each but the device is
sending a 15 byte packet? My guess is one of them gets the first 10 bytes,
the other one a shortened read of the remaining 5. Unless we are talking
about a device which provides a lseek(2) operation, I don't see how to get
around. Should we just drop these 5 bytes because they were triggered by
the other process' read'ing only partially so the following process gets
the tail of the packet? - bad idea I believe: every concurrent reader
might trigger such data dumps.
> In addition you now have to deal with incomplete buffers.
> This is getting complicated.
Even worse, if you think about writing. What count should we return: the
number of bytes we've placed in successfully _submitted_ urb's - or the
number of bytes for which the urb's are succesfully _finished_ at this
moment.
First approach: process would never now, if one of the pending urb's
somehow fails - data lost.
Second approach: we would have to wait for synchrous unlink of the pending
urb's before handling the signal (latency!) - bad too and doesn't
help either: see below for reason.
Sounds like implementing O_SYNC would help. But this leads us to the next
problems: missing ACK on OUT packet for example. If the host doesn't get
an ACK from the device for a packet it has sent, it will retry. DATA0/1
toggles provide means to detect and recover from this situation. But what
if you decide to cancel(unlink) the urb at this point? You'll never know
whether the data arrived at the device and the ACK got lost or the data
was corrupted for example and the device intensionally did not sent the
ACK. No way to decide without retry. So what do you tell the writing
process: was the last packet successfully written to the device or not?
My point is: as long as you _never_ unlink or timeout a pending urb, you
have data consistency guaranteed by USB-layer. The unlink is the bad
thing, IMHO. Ok, it's not worse than a disconnect in the middle of a
transfer of course. My conclusion is, whenever you need data consistency
you have to implement a transaction-like protocol on top of USB. This is
of course device-/class-specific - at least the mass-storage class should
provide this.
> > 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.
Depends on your point of view, IMHO. There is one single entity called
"file". There may be 0, 1 or several processes operating on this file
using an individual instance of a file descriptor always refering to one
single file. At some point this file may have an error pending due to some
operation triggered in the past. Any process might see this error when
executing file operations.
> > 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 ?
Somebody please correct me if I'm wrong, but IIRC nothing which may block
is acceptable to call from a signal handler - at least according to POSIX?
> > 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.
On blocking close(2), yes. But not on pending signal IMHO, as explained
above.
Martin
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
