It currently works by scheduling a post-flush tqueue handler which
enables RTS and RDI if they had previously been disabled. This is a
problem, because the line discpline may have cleared RTS because its
upper level buffering had filled. So simply always enabling RTS after
the line discpline flush is a bad thing, and may result in significant
numbers if the line discpline needed to exert flow control for some
reason. This isn't an issue with PPP (which is probably why Rob didn't
think of it), but it is an issue with the N_TTY line discpline.
So I wouldn't apply this patch at all if you use any non-PPP
applications on your serial lines (i.e., dialup login, UUCP, etc.)
By the way, given that the PPP is already wasting CPU time to check the
flags field (which is unnecessary, given that it's calculating a
checksum anyway, and you optimize for the common case, which is a
non-corrupted packet), you might as well have it check to see if there
are FIFO overruns and have it print a warning diagnostic. This way
you'll be able to distinguish between FIFO overruns caused by interrupt
latency, and flip buffer overruns.
- Ted