Messages in this thread | | | Date | Thu, 24 Jul 1997 08:07:28 -0600 (MDT) | From | Rob Riggs <> | Subject | Re: 2.0.30 serial.c, ppp.c and pppd-2.2 questions |
| |
On 24-Jul-97 Theodore Y. Ts'o wrote: > >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*,
If you are refering to the fact that large switch contruct that does nothing in the default (bad trigger level) case, I did that on purpose. The code that checks the validity of the FIFO size is in set_serial_info() and does work properly. I wanted to make sure that if the logic in that piece was wrong, or that I had made a mistake in setting the default trigger levels, I would notice it immediately.
>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.
No, I just forgot :)
I noticed it early on in the development, realized it would not impact me and ignored it. I did not expect to be publishing a patch, so I let it slip my mind.
>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.)
Good advise for now. I will try to get that fixed ASAP.
-Rob
| |