> 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.
We must not drop data, except perhaps on final close.
> > 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.
Definitely finished urbs.
> 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?
Signals arriving during error recovery should be rare.
If it happens, data loss is worse than bad latency.
> 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
If you never timeout, there's no need for a timeout ;-)
We need to deal with it.
> 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.
I think we need to handle signals without data loss in all cases.
Do you have the standards at hand. That should be covered.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
