lkml.org 
[lkml]   [1997]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2011 Jasper Spaans