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

[Paul Fulghum <paulkf@microgate.com>]

Alan Cox wrote:
> On Sat, 5 May 2007 20:07:15 +0200
> Oliver Neukum <oliver@neukum.org> wrote:
>> should I understand this so that, if tty_buffer_request_room() returns
>> less than requested, the rest of the data should be dropped on the
>> floor?
> 
> If it returns NULL then either there is > 64K buffered (we can adjust
> that if anyone shows need - its just for sanity) or the system is out of
> RAM. 


It sounds bad, but I think dropping the data make sense with the
new tty buffering code.

My interpretation of the tty buffering is that
it is intended to be the main receive buffer facility
for the driver.

It simplifies and centralizes these functions so
the driver does not need implement policies such as when to
flush for user request, expand under load, crop when too large.

It should not be the driver's responsibility to
try and work around the tty buffering if it becomes full.
That adds other complexity such as when the driver should
attempt to push the data again: when more data is received?
after a timeout?

If the tty buffering runs dry, then maybe put out an error message.
If the losses occur too often then the tty buffering code needs to
be adjusted.

--
Paul