Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

["Antonino Ingargiola" <tritemio@gmail.com>]

2007/5/6, Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > However, whatever policy the buffer uses, the fundamental point it's that
> > when I flush the input buffer I should be sure that each byte read
> > after the flush is *new* (current) data and not old one. This because
>
> Define "new" and "old" in this case. I don't believe you can give a
> precise definition or that such a thing is physically possible.

You are right. In the case of buffers storing the *last* N bytes
received we always get "new" data. To be precise if we get a byte each
T seconds
we can read data N*T seconds old (worst case). This is a bound, known,
and perfectly acceptable jitter.

Let see instead the case a not flushable buffer in the chain (inside
the PC) uses the policy of storing the *first* N bytes received. That
is the case for the flip buffer in mainline. In this case we can read
bytes also one hour old, if we read the first byte one hour after the
external device begun to send data. This is an unbound, unknown and
thus unacceptable error in a measurement (think if we were acquiring a
physical "realtime" sampled quantity). That was exactly my original
problem causing data corruption in case of multi-byte data. Paul
Fulghum patches fix this problem for serial port and for the cdc-acm
driver making the "secondary buffers" flushable.

So, in general, all the buffers (in the host) that store the first
received N bytes (as policy) should be flushable in order to don't
read (potentially very) "old" data after we made a flush.

I understand that some internal HW buffer can be not flushable via
software, but in this case I doubt the buffer use the
store-the-first-N-bytes policy.
And even if some particular device does this, than it's *its* fault, not linux.

To conclude, the store the *last* N bytes received seems a more
reasonable policy for the input buffers managed by the kernel. If the
other policy is used (as tty does), then the kernel should flush all
the buffers he *can* physically flush, remaining inside the host
computer of course.

Hope my English is sufficiently clear.


Regards,

 ~ Antonio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/