Re: 2.0.30 serial.c, ppp.c and pppd-2.2 questions

Theodore Y. Ts'o (tytso@MIT.EDU)
Thu, 24 Jul 1997 09:03:43 -0400

I just finished taking a quick look at Rob's patches, and besides some
design problems I have with it (if you specify an FIFO size which isn't
supported by your UART, it silently turns the FIFO completely *OFF*,
which may be a bit surprising to the user), there's one big problem with
the patch.

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